[要約] RFC 4678は、サーバー/アプリケーションの状態プロトコルv1に関する要約と目的を提供します。このプロトコルは、サーバーとアプリケーション間で状態情報を交換するための標準化された方法を提供することを目的としています。
Network Working Group A. Bivens
Request for Comments: 4678 IBM Research
Category: Informational September 2006
Server/Application State Protocol v1
サーバー/アプリケーション状態プロトコルV1
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 (2006).
Copyright（c）The Internet Society（2006）。
IESG Note
IESGノート
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCは、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、RFC 3932を参照してください。
Abstract
概要
Entities responsible for distributing work across a group of systems traditionally do not know a great deal about the ability of the applications on those systems to complete the work in a satisfactory fashion. Workload management systems traditionally know a great deal about the health of applications, but have little control over the rate in which these applications receive work. The Server/Application State Protocol (SASP) provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members.
システムのグループ全体に作業を配布する責任のあるエンティティは、従来、それらのシステム上のアプリケーションの能力について十分なことを十分に知りません。ワークロード管理システムは、従来、アプリケーションの健康について多くのことを知っていますが、これらのアプリケーションが作業を受けるレートを制御できません。Server/Application State Protocol（SASP）は、既存のワークロードをグループメンバーに配布するより良い方法を伝えるために、ロードバランサーとワークロード管理システムのメカニズムを提供します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Overview ...................................................3
1.2. Identities .................................................4
2. Requirements Notation ...........................................4
3. Conventions Used in This Document ...............................4
4. General Message Structure .......................................4
4.1. TLV Structure ..............................................6
4.2. Component Types ............................................6
4.3. SASP Protocol Header .......................................7
4.4. Version Negotiation ........................................8
5. Singular Protocol Components ....................................9
5.1. Member Data Component ......................................9
5.2. Group Data Component ......................................11
5.3. Weight Entry Data Component ...............................12
5.4. Member State Instance Component ...........................14
6. Group Protocol Components ......................................15
6.1. Group of Member Data Component ............................15
6.2. Group of Weight Data Component ............................16
6.3. Group of Member State Data Components .....................17
7. Protocol Messages ..............................................17
7.1. Registration Request and Reply ............................18
7.1.1. Registration Request ...............................18
7.1.2. Registration Reply .................................19
7.2. DeRegistration Request and Reply ..........................20
7.2.1. DeRegistration Request .............................21
7.2.2. DeRegistration Reply ...............................22
7.3. Get Weights Request and Reply .............................23
7.3.1. Get Weights Request ................................24
7.3.2. Get Weights Reply ..................................25
7.4. Send Weights ..............................................26
7.5. Set Member State Request and Reply ........................27
7.5.1. Set Member State Request ...........................28
7.5.2. Set Member State Reply .............................29
7.6. Set Load Balancer State Request and Reply .................30
7.6.1. Set LB State Request ...............................30
7.6.2. Set LB State Reply .................................32
8. Example of SASP Message Encoding ...............................32
9. Protocol Flow ..................................................37
9.1. Normal Protocol Flow ......................................37
9.2. Behavior in Error Cases ...................................39
9.3. Example Flow 1: Load Balancer Registration,
Getting Weights, and Application-Side Quiescing ...........41
9.4. Example Flow 2: Set Load Balancer State, Application
Registration, and Load Balancer Group DeRegistration ......43
9.5. Avoiding Single Points of Failure .........................44
10. Security Considerations .......................................45
11. Normative References ..........................................46
Appendix A. Acknowledgements ......................................47
The Server/Application State Protocol is designed to enable load balancers or schedulers (1) to receive traffic weight recommendations from Workload Managers, (2) to register with Workload Managers members of load balancing/scheduling groups, and (3) to enable Workload Managers to suggest new load balancing group members to load balancers and schedulers
サーバー/アプリケーションの状態プロトコルは、ロードバランサーまたはスケジューラ（1）ワークロードマネージャーからトラフィック重量の推奨事項を受け取ることができるように設計されています。ロードバランサーとスケジューラーに新しい負荷分散グループメンバーを提案する
The figure below shows where the SASP entities are in typical load balancing topology.
次の図は、SASPエンティティが典型的な負荷分散トポロジのどこにあるかを示しています。
----------
| Group |
-------->|Member 1|<--|
| ---------- |
| |
--------- ---------- | ---------- |
|Request|<------>| Load |---| | Group | |
|Origins|<------>|Balancer|----------->|Member 2|<--|
--------- | |---| ---------- |
---------- | |
^ | ---------- |
| -------->| Group | |
SASP | |Member 3|<--|
------- ---------- |
| |
| -------------------- |
| | Group | SASP |
------>| Workload Manager |<----------
--------------------
Figure 1
図1
SASP is a binary protocol that facilitates communication from load balancers/schedulers to Workload Managers. The connection between the Group Workload Manager (GWM) and the load balancer/scheduler is expected to be a long-running TCP connection. In SASP interactions, the GWM acts as a SASP server waiting to receive connections from the other SASP components. Server port 3860 has been registered with the IANA for SASP communications. It is expected that all SASP components are configured with the DNS name of the GWM to develop this connection. Security in SASP is handled by transporting binary messages over Secure Socket Layer/Transport Layer Security (SSL/TLS). This document only describes the message format and protocol behavior above the connection and security layers. Connection and security aspects including SSL's authentication and encryption will be implementation specific.
SASPは、ロードバランサー/スケジューラからワークロードマネージャーへの通信を促進するバイナリプロトコルです。グループワークロードマネージャー（GWM）とロードバランサー/スケジューラの間の接続は、長期にわたるTCP接続になると予想されます。SASP相互作用では、GWMは他のSASPコンポーネントから接続を受信するのを待っているSASPサーバーとして機能します。サーバーポート3860は、SASP通信のためにIANAに登録されています。この接続を開発するために、すべてのSASPコンポーネントがGWMのDNS名で構成されていることが予想されます。SASPのセキュリティは、安全なソケットレイヤー/トランスポートレイヤーセキュリティ（SSL/TLS）を介してバイナリメッセージを輸送することにより処理されます。このドキュメントでは、接続レイヤーとセキュリティレイヤーの上のメッセージ形式とプロトコルの動作のみを説明します。SSLの認証と暗号化を含む接続とセキュリティの側面は、実装固有のものになります。
SASP identifies a load balancer by a UTF-8 string called a "LB UID". A group of "equivalent" servers providing a service is identified by a UTF-8 string called a "Group Name", which is interpreted in the context of the LB UID. A server is identified by its IP address and (optional) port and protocol numbers. A GWM is only identified implicitly as the entity on the other end of the TCP connection from a load balancer or group member. All of these identifiers are local; there are no globally unique identifiers. The LB UID and GroupName fields are unstructured so that components could assign values to these fields that are meaningful to an administrator. For example, in many cases, a load balancer would use the name an administrator provided for the serverfarm group as the groupname in a SASP-specified group. Since the naming options in industry load balancers do not carry explicit naming restrictions, SASP naming options also carry no naming restrictions.
SASPは、「LB UID」と呼ばれるUTF-8文字列でロードバランサーを識別します。サービスを提供する「同等の」サーバーのグループは、LB UIDのコンテキストで解釈される「グループ名」と呼ばれるUTF-8文字列によって識別されます。サーバーは、IPアドレスと（オプションの）ポートおよびプロトコル番号によって識別されます。GWMは、ロードバランサーまたはグループメンバーからのTCP接続の反対側のエンティティとして暗黙的にのみ識別されます。これらの識別子はすべてローカルです。グローバルに一意の識別子はありません。LB UIDおよびGroupNameフィールドは非構造化されているため、コンポーネントが管理者にとって意味のあるこれらのフィールドに値を割り当てることができます。たとえば、多くの場合、ロードバランサーは、SASP指定グループのグループ名としてServerFarmグループに提供される管理者の名前を使用します。業界の命名オプションは、明示的な命名制限を担当していないため、SASPの命名オプションには命名制限もありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
o Load Balancer - Entity responsible for distributing requests amongst the available members.
o Load Balancer-利用可能なメンバー間でリクエストの配布を担当するエンティティ。
o Member - Machine, process, or application used to service requests.
o メンバー - リクエストのサービスに使用されるマシン、プロセス、またはアプリケーション。
o Group Workload Manager (GWM) - Entity responsible for reporting or managing a group of members on multiple machines.
o Group WorkLoad Manager（GWM） - 複数のマシンでメンバーのグループを報告または管理するエンティティ。
Any string interpreted by the group workload manager is assumed to use UTF8. Components implementing SASP MUST support the printable ASCII subrepertoire of UTF8 (0x20-0x7E). Components MAY also choose to provide support for additional UTF8 character encodings. It is recommended that customers using SASP-enabled products configure the string-generating components (load balancers and group members) to use the same character repertoire.
グループワークロードマネージャーによって解釈される文字列は、UTF8を使用すると想定されています。SASPを実装するコンポーネントは、UTF8の印刷可能なASCIIサブレパートリー（0x20-0x7E）をサポートする必要があります。コンポーネントは、追加のUTF8文字エンコーディングのサポートを提供することもできます。SASP対応製品を使用している顧客は、同じ文字レパートリーを使用して、文字列生成コンポーネント（ロードバランサーとグループメンバー）を構成することをお勧めします。
Many of the SASP structures involve the transfer of multi-byte integer values. In all cases where multi-byte integer values are used, they are considered to be in network-byte order (big-endian).
SASP構造の多くには、多バイト整数値の転送が含まれます。マルチバイトの整数値が使用されるすべての場合において、それらはネットワークバイト順序（ビッグエンディアン）であると見なされます。
SASP is organized into several message components. For extendibility and ease of processing, each message component is described in a TLV (Type, Length, Value) format. An illustration of the SASP structure can be found in the example below. The first section is the header followed by the message component type. As mentioned, the header, message component, and all other components have a TLV format. Each component value contains a variable number of fields, some of which refer to upcoming components (explained component descriptions are in upcoming sections). After the first message component, any number of additional components may be included (as stipulated in the fields of the message type).
SASPはいくつかのメッセージコンポーネントに編成されています。拡張性と処理の容易さのために、各メッセージコンポーネントはTLV（タイプ、長さ、値）形式で説明されています。SASP構造の図は、以下の例にあります。最初のセクションは、ヘッダーに続くメッセージコンポーネントタイプです。前述のように、ヘッダー、メッセージコンポーネント、および他のすべてのコンポーネントには、TLV形式があります。各コンポーネント値には、さまざまな数のフィールドが含まれており、その一部は今後のコンポーネントを参照しています（説明されたコンポーネントの説明は、今後のセクションにあります）。最初のメッセージコンポーネントの後、任意の数の追加コンポーネントを含めることができます（メッセージタイプのフィールドに規定されています）。
-------------------------------------------------
| |T| Type (SASP Header Type) |
| SASP |----------------------------------|
| Header |L| Length of SASP header TLV |
| |----------------------------------|
| |V| Header fields |
|-----------------------------------------------|
| |T| Type (Message Type) |
| Message |----------------------------------|
| Type |L| Length of this Message Type TLV|
| Component |----------------------------------|
| |V| Component fields |
|-----------------------------------------------|
| |T| Type (Component Type) |
| |----------------------------------|
|Component-1 |L| Length of this TLV |
| |----------------------------------|
| |V| Component fields |
|-----------------------------------------------|
| ... |
|-----------------------------------------------|
| |T| Type (Component Type) |
| |----------------------------------|
|Component-n |L| Length of this TLV |
| |----------------------------------|
| |V| Component fields |
-------------------------------------------------
Figure 2
図2
An illustration of the TLV format is shown below. The Type is a two-byte field containing a binary value for the component type. The Length is a two-byte field containing the size of the TLV in bytes (including the Type and Length fields). The Value field is a variable-length field that actually contains the data of the component.
TLV形式の図を以下に示します。このタイプは、コンポーネントタイプのバイナリ値を含む2バイトフィールドです。長さは、バイト単位のTLVのサイズを含む2バイトフィールド（タイプと長さのフィールドを含む）です。値フィールドは、コンポーネントのデータを実際に含む可変長さフィールドです。
< xxxx xxxx xxxx xxxx, xxxx xxxx xxxx xxxx, xxxx...........xxxx >
|-----------------| |-----------------| |-----------------|
Type(2 bytes) Length(2 bytes) Value(variable)
Figure 3
図3
The TLV structure requires a type value for each protocol component. All SASP types are listed in this section.
TLV構造には、各プロトコルコンポーネントの型値が必要です。このセクションには、すべてのSASPタイプがリストされています。
Reserved 0x0000-0x1000
予約された0x0000-0x1000
Message Types
メッセージタイプ
Registration Request 0x1010
登録リクエスト0x1010
Registration Reply 0x1015
登録返信0x1015
DeRegistration Request 0x1020
解雇要求0x1020
DeRegistration Reply 0x1025
解雇の返信0x1025
Get Weights Request 0x1030
ウェイトリクエスト0x1030を取得します
Get Weights Reply 0x1035
ウェイトを取得します返信0x1035
Send Weights 0x1040
重量0x1040を送信します
Set Load Balancer State Request 0x1050
ロードバランサー状態リクエスト0x1050を設定します
Set Load Balancer State Reply 0x1055
ロードバランサー状態の応答を設定します0x1055
Set Member State Request 0x1060
加盟国のリクエスト0x1060を設定します
Set Member State Reply 0x1065
加盟国の応答を設定0x1065
Utility Component Types
ユーティリティコンポーネントタイプ
SASP Header 0x2010
SASPヘッダー0x2010
Singular Component Types
特異コンポーネントタイプ
Member Data 0x3010
メンバーデータ0x3010
Group Data 0x3011
グループデータ0x3011
Weight Entry Data 0x3012
重量入力データ0x3012
Member State Instance 0x3013
加盟国インスタンス0x3013
Group Component Types
グループコンポーネントタイプ
Group of Member Data 0x4010
メンバーデータのグループ0x4010
Group of Weight Entry Data 0x4011
重量入力データのグループ0x4011
Group of Member State Data 0x4012
加盟国データのグループ0x4012
Reserved 0xF000-0xFFFF
予約済み0xf000-0xffff
An illustration of the SASP Header is found in the table below. It is expected that every message will start with the SASP Protocol Header component.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SASP header type (0x2010) | Size of this TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+
Figure 4
図4
o Version: The version of the protocol used in this message.
o バージョン：このメッセージで使用されているプロトコルのバージョン。
o Message Length: A 4-byte signed integer value representing the total length of the SASP message. It is said to be a signed 4-byte value to make any Java implementations easier (or any other implementations without unsigned values); however, no negative lengths are valid.
o メッセージの長さ：SASPメッセージの全長を表す4バイトの署名された整数値。Javaの実装（または署名されていない値のない他の実装）をより簡単にするために、署名された4バイト値であると言われています。ただし、負の長さは有効ではありません。
o Message ID: Each request message is given a 4-byte Message ID by the message originator, which is simply returned in the Message ID field of the reply. This field is meant to assist the requester in correlating replies to the appropriate request when many requests have been sent. In the Send Weights message (the only message transaction that has no reply), this field serves no purpose.
o メッセージID：各リクエストメッセージには、メッセージオリジネーターによって4バイトのメッセージIDが与えられます。これは、返信のメッセージIDフィールドに単純に返されます。このフィールドは、多くのリクエストが送信されたときに、適切なリクエストに返信を相関させる際に要求者が支援することを目的としています。送信ウェイトメッセージ（返信がない唯一のメッセージトランザクション）では、このフィールドは目的を果たしません。
To negotiate the version of the protocol used by the entities involved in the connection, the GWM views the version included in the load balancer request as the load balancer's proposed version.
接続に関与するエンティティが使用するプロトコルのバージョンをネゴシエートするために、GWMはロードバランサーリクエストに含まれるバージョンをロードバランサーの提案バージョンと見なします。
If the GWM supports the version proposed by the load balancer, it will respond to the connection with the appropriate response code and the load balancer's proposed version in the response header. This proposed version should be the version used for all messages in this connection.
GWMがロードバランサーによって提案されたバージョンをサポートしている場合、応答ヘッダーの適切な応答コードとロードバランサーの提案バージョンとの接続に応答します。この提案されたバージョンは、これに関連してすべてのメッセージに使用されるバージョンである必要があります。
If the GWM does not support the version proposed by the load balancer, the GWM will respond with a "message not understood" response code and the GWM's highest supported SASP version in the version field of the response header. This is an indication for the load balancer to come down to GWM's SASP version level.
GWMがロードバランサーによって提案されたバージョンをサポートしていない場合、GWMは「メッセージが理解されていない」応答コードと、応答ヘッダーのバージョンフィールドにあるGWMの最高サポートSASPバージョンで応答します。これは、Load BalancerがGWMのSASPバージョンレベルに到達する兆候です。
The most basic of SASP components are singular components because they describe a single instance of a member, member resource, member weight, or group. Some of the SASP components reuse other SASP components. When this is the case, any component being reused by a base component will simply be given immediately following the base component. Some examples of this technique are seen and explained in the Weight Entry and Member State Instance components.
SASPコンポーネントの最も基本的なコンポーネントは、メンバー、メンバーリソース、メンバーの重量、またはグループの単一のインスタンスを記述するため、単数のコンポーネントです。SASPコンポーネントの一部は、他のSASPコンポーネントを再利用します。この場合、ベースコンポーネントによって再利用されるコンポーネントは、ベースコンポーネントの直後に単純に与えられます。この手法のいくつかの例は、重量入力および加盟国インスタンスコンポーネントで見られ、説明されています。
The member data component describes a particular member and is referred to by other components.
メンバーデータコンポーネントは、特定のメンバーを記述し、他のコンポーネントによって参照されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member Data Type (0x3010) | Size of this TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Port | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ IP Address of Member +
| |
+ +-+-+-+-+-+-+-+-+
| | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Label .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
図5
o Protocol: The assigned number of the IP transport layer used in the Protocol Field of the IP header. These are defined in [RFC1700]; however, a current list is maintained at http://www.iana.org. for example: TCP = 0x06, UDP = 0x11, etc.
o プロトコル：IPヘッダーのプロトコルフィールドで使用されるIP輸送層の割り当てられた番号。これらは[RFC1700]で定義されています。ただし、現在のリストはhttp://www.iana.orgに維持されています。たとえば、TCP = 0x06、udp = 0x11など。
o Port: The port number used for communication to the member. *** A value of 0 can be given for the Protocol and Port to signify a system level member. However, 0 shouldn't be perceived as a wildcard for either Port or Protocol fields (i.e., a deregistration request that includes a MemberData component with a 0 for the port doesn't mean deregister all applications listening on any port of that IP and protocol).
o ポート：メンバーへの通信に使用されるポート番号。***プロトコルとポートには、システムレベルのメンバーを意味する値0を指定できます。ただし、ポートフィールドまたはプロトコルフィールドのワイルドカードとして0を認識すべきではありません（つまり、ポートの0を持つメンバーDATAコンポーネントを含む登録リクエストは、そのIPおよびプロトコルのポートでリスニングされるすべてのアプリケーションを登録することを意味しません）。
o IP Address: The current format is described by the following 16 bytes, where IPv4 addresses are represented as "IPv4-compatible IPv6 addresses" [RFC4291]. In the following example, the x's and zeros represent 4-bit hex values. The x's describe arbitrary hex values.
o IPアドレス：現在の形式は、次の16バイトで説明されており、IPv4アドレスは「IPv4互換IPv6アドレス」[RFC4291]として表されます。次の例では、X'sとZerosは4ビット16進値を表します。Xは、任意の六角値を説明しています。
IPv4 Address: 00 00 00 00 00 00 00 00 00 00 00 00 xx xx xx xx
IPv4アドレス：00 00 00 00 00 00 00 00 00 00 00 00 XX XX XX XX
IPv6 Address: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
IPv6アドレス：XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
o Label length: The length, in bytes, of the label string to follow.
o ラベルの長さ：続くラベル文字列の長さ、バイト単位の長さ。
o Label: A UTF8 string that may be set while registering a member. This string is opaque to the GWM and is simply included with any correspondence containing the member data component. Note that the size of this label is <= 255 bytes. Because UTF8 character encodings may be up to 6 bytes, care must be exercised by the load balancer or member to make sure the UTF8 string it sends the GWM is in fact <= 255 bytes.
o ラベル：メンバーの登録中に設定できるUTF8文字列。この文字列はGWMに不透明であり、メンバーデータコンポーネントを含む通信に単純に含まれています。このラベルのサイズは<= 255バイトであることに注意してください。UTF8文字のエンコーディングは最大6バイトのものである可能性があるため、GWMを送信するUTF8文字列が実際に<= 255バイトであることを確認するために、ロードバランサーまたはメンバーが注意する必要があります。
The group data component simply describes a group with which to associate other singular components.
グループデータコンポーネントは、他の特異コンポーネントを関連付けるグループを単に記述します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Data Type (0x3011) | Size of this TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB UID Length | |
+-+-+-+-+-+-+-+-+ +
. .
. LB UID .
. .
+ +-+-+-+-+-+-+-+-+
| |Group Name Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Group Name .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
図6
o LB UID Length: Length of the LB UID to follow (in bytes).
o LB UIDの長さ：続くLB UIDの長さ（バイト単位）。
o LB UID: A UTF8 string used as a unique identifier and a context for the Group Name (e.g., a UTF8 representation of the MAC address of the load balancer or some type of Universally Unique Identifier (UUID)). This string is used by the Group Workload Manager to associate application registration and deregistration, and to set state messages with the correct load balancer. This unique identifier should not be any longer than 64 bytes.
o LB UID：ユニークな識別子とグループ名のコンテキストとして使用されるUTF8文字列（たとえば、ロードバランサーのMACアドレスのUTF8表現またはある種の普遍的に一意の識別子（UUID））。この文字列は、グループワークロードマネージャーによって、アプリケーションの登録と解体を関連付け、正しいロードバランサーで状態メッセージを設定するために使用されます。この一意の識別子は、64バイト以下であってはなりません。
o Group Name Len: Length of the Group Name field to follow (in bytes).
o グループ名レン：従うべきグループ名フィールドの長さ（バイト単位）。
o Group Name: A UTF8 string the load balancer has chosen to tell the Group Workload Manager that members being registered with this Group Name are equivalent in function. In Get Weight and DeRegistration messages, the Group Name may be omitted (Group Name Length = 0) to indicate all groups from the associated load balancer.
o グループ名：AUTF8文字列ロードバランサーは、このグループ名に登録されているメンバーが機能が同等であることをグループワークロードマネージャーに伝えることを選択しました。Get Weight and Deregistrationメッセージでは、グループ名を省略して（グループ名= 0）省略して、関連するロードバランサーのすべてのグループを示します。
The Weight Entry Component is used by the get and send weight messages to associate a weight with a particular member (or Member Data). It also uses an opaque member state field and a general member flags field to denote extra information about a member (described below). When the Weight Entry component is used, the Member Data TLV it refers to is listed first, immediately followed by the Weight Entry TLV.
Weight Entryコンポーネントは、GETおよびWeightメッセージを送信して、重量を特定のメンバー（またはメンバーデータ）に関連付けるために使用されます。また、不透明なメンバー州フィールドと一般的なメンバーフラグフィールドを使用して、メンバーに関する追加の情報を示します（以下に説明）。ウェイトエントリコンポーネントを使用すると、それが言及するメンバーデータTLVが最初にリストされ、すぐにウェイトエントリTLVが続きます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member Data Type (0x3010) | Size of this Member Data TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Member Data Fields .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight Entry Type (0x3012) | Size of this Weight Entry TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State Field | Flags Field | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7
図7
o State Field: This field is used by the member to communicate state information to the scheduler. The information placed in this field is opaque to the GWM and will simply be forwarded to the scheduler with the member weights. There are no defined values for this field.
o ステートフィールド：このフィールドは、メンバーが州の情報をスケジューラに伝えるために使用されます。このフィールドに配置された情報は、GWMに不透明であり、メンバーの重量でスケジューラに転送されます。このフィールドに定義された値はありません。
o Flags Field: This field has several flag values that describe several attributes of the member.
o フラグフィールド：このフィールドには、メンバーのいくつかの属性を記述するいくつかのフラグ値があります。
A. Contact Success Flag (set by the GWM): describes whether the member is currently running. If the contact success flag is off, this member should be avoided by the load balancer.
A.連絡先の成功フラグ（GWMが設定）：メンバーが現在実行しているかどうかを説明します。連絡先の成功フラグがオフの場合、このメンバーはロードバランサーによって避ける必要があります。
+ xxxx xxx1 The GWM has located this running system or application.
+ xxxx xxx1 GWMは、この実行システムまたはアプリケーションを配置しています。
+ xxxx xxx0 The GWM has not located this running system or application.
+ XXXX XXX0 GWMは、この実行システムまたはアプリケーションを配置していません。
B. Quiesce Flag (set by the load balancer or Member): used when an administrator would like to temporarily remove a member from the weight calculation, but not deregister it from the group. When quiesced, the member will still show up in the weights, but the quiesce flag will be set, and its weight will be zero. When the administrator returns this member to active, the quiesce flag will be 0, and a weight will be provided. If the quiesce flag is on, this member should be avoided by the load balancer.
B. Quiesceフラグ（ロードバランサーまたはメンバーによって設定）：管理者が一時的にメンバーを重量計算から削除したいが、グループからの登録はしない場合に使用します。Quiescedの場合、メンバーは引き続き重量に表示されますが、Quiesceフラグが設定され、その重量はゼロになります。管理者がこのメンバーをアクティブに戻すと、Quiesceフラグは0になり、重量が提供されます。Quiesceフラグがオンの場合、このメンバーはロードバランサーによって避ける必要があります。
+ xxxx xx1x The member is quiesced.
+ xxxx xx1xメンバーはQuiescedです。
+ xxxx xx0x The member is active (not quiesced).
+ xxxx xx0xメンバーはアクティブです（Quiescedではありません）。
C. Registration Flag (set by the GWM): stores how the member was registered.
C.登録フラグ（GWMによって設定）：メンバーの登録方法を保存します。
+ xxxx x1xx This member has been registered by the load balancer/scheduler.
+ XXXX X1XXこのメンバーは、ロードバランサー/スケジューラによって登録されています。
+ xxxx x0xx This member has registered itself.
+ xxxx x0xxこのメンバーはそれ自体を登録しました。
D. Confident Flag (set by the GWM): describes whether the GWM has knowledge of this member's state. If this flag is off for only some of the members in the group while the remaining members have valid weights, the load balancer should avoid sending work to those members with the confident flag off. If the confident flag is off for all valid group members, the load balancer should disregard any recommendation from the GWM until the confident flag comes back on for at least one member. In this case where all confident flags are off, the load balancer should determine the correct distribution of work by other means (perhaps a different advisor, previously configured static weights, etc.).
D. Confide Flag（GWMが設定）：GWMがこのメンバーの状態に関する知識を持っているかどうかを説明します。残りのメンバーが有効なウェイトを持っている間、グループ内のメンバーの一部のみがこのフラグがオフになっている場合、ロードバランサーは自信のあるフラグを持つメンバーに作業を送ることを避ける必要があります。すべての有効なグループメンバーに対して自信のあるフラグがオフになっている場合、ロードバランサーは、少なくとも1人のメンバーのために自信のあるフラグが戻ってくるまで、GWMからの推奨を無視する必要があります。この場合、すべての自信のあるフラグがオフになっている場合、ロードバランサーは他の手段（おそらく別のアドバイザー、以前に構成された静的な重みなど）によって正しい作業分布を決定する必要があります。
The goal of the confident flag is to convey to the load balancer that it should look to other methods of distribution recommendations if the GWM cannot give recommendations for any of the valid group members. If some members of the group have the confident flag on but the contact flag off or the quiesced flag on (meaning these members should always be avoided) while the remaining members of the group have their confident flag off, the load balancer should determine the appropriate distribution of work for those members with the confident flag off by other means.
自信のあるフラグの目標は、GWMが有効なグループメンバーのいずれにも推奨事項を提供できない場合、他の配布推奨方法に目を向けるべきであることをロードバランサーに伝えることです。グループの一部のメンバーは自信のあるフラグを立てていますが、連絡先フラグがオフまたはQuiesced Flagの場合（これらのメンバーは常に避けるべきです）、グループの残りのメンバーが自信のあるフラグをオフしている場合、ロードバランサーは適切なものを決定する必要があります他の手段で自信を持って旗を掲げたメンバーの作業の分配。
+ xxxx 1xxx GWM has determined it has knowledge of the state of this member.
+ XXXX 1XXX GWMは、このメンバーの状態に関する知識があると判断しました。
+ xxxx 0xxx GWM has no knowledge of the state of this member.
+ xxxx 0xxx gwmは、このメンバーの状態に関する知識がありません。
E. Leftmost four bits are reserved (0000 xxxx - 1111 xxxx).
E.左端の4ビットは予約されています（0000 xxxx -1111 xxxx）。
o Weight: This field represents the GWM's recommendation for the relative amount of work that should be sent to this member. This is a 16-bit field with a possible range of 0 to 65536. Load balancers should be prepared to receive a wide range of weight values. Load balancers with limited maximum weight values may restrict the granularity of management by the GWM and in turn cause less than optimal performance. Many existing implementations have supported a minimum raw weight range from 0 to 100.
o 重量：このフィールドは、このメンバーに送信されるべき作業の相対量に対するGWMの推奨を表しています。これは、0〜65536の可能性のある範囲の16ビットフィールドです。ロードバランサーは、幅広い重量値を受信するために準備する必要があります。限られた最大体重値を持つロードバランサーは、GWMによる管理の粒度を制限し、最適なパフォーマンスよりも少なくなります。多くの既存の実装は、0〜100の最小生の重量範囲をサポートしています。
The Member State Instance Component is used by the set member state message to indicate the sender's perceived state of the member mentioned. This component is used to set values that will ultimately end up in the WeightEntry component. When the Member State Instance component is used, the Member Data TLV it refers to is listed first, immediately followed by the Member State Instance TLV.
Member State Instanceコンポーネントは、Set Member Stateメッセージによって使用され、言及されたメンバーの送信者の認識された状態を示します。このコンポーネントは、最終的に重みのコンポーネントになる値を設定するために使用されます。Member State Instanceコンポーネントを使用すると、最初にリストされているメンバーデータTLVがリストされ、すぐにMember State Instance TLVが続きます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member Data Type (0x3010) | Size of this Member Data TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Member Data Fields .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member State Instance(0x3013) | Size of Member State Inst TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State Field | Flags Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8
図8
o State Field: This field is used by the member to communicate state information to the load balancer or scheduler. There are no defined values for this field.
o ステートフィールド：このフィールドは、メンバーが状態情報をロードバランサーまたはスケジューラに伝えるために使用されます。このフィールドに定義された値はありません。
o Flags Field: This field describes attributes of the member. Currently the only flag value defined is that of the quiesce flag. The quiesce flag is used when an administrator would like to temporarily remove a member from the weight calculation, but not deregister it from the group. When quiesced, the member will still show up in the weights, but the quiesce flag will be set, and its weight will be zero. When the administrator returns this member to active, the quiesce flag will be 0, and a weight will be provided.
o フラグフィールド：このフィールドは、メンバーの属性について説明します。現在、定義されている唯一のフラグ値は、Quiesceフラグの値です。管理者がメンバーを一時的に重量計算から削除したいが、グループから登録することはない場合に使用される場合に使用されます。Quiescedの場合、メンバーは引き続き重量に表示されますが、Quiesceフラグが設定され、その重量はゼロになります。管理者がこのメンバーをアクティブに戻すと、Quiesceフラグは0になり、重量が提供されます。
A. Quiesce Flag
A. Quiesceフラグ
+ xxxx xxx1 The member or load balancer setting this state is quiescing this member.
+ XXXX XXX1メンバーまたはロードバランサーこの状態を設定しているのは、このメンバーをQuiesceしています。
+ xxxx xxx0 The member or load balancer setting this state is placing the member in a non-quiesced state.
+ xxxx xxx0メンバーまたはロードバランサー設定この状態は、メンバーをQuiesced Nats状態に配置しています。
B. Leftmost seven bits are reserved (0000 000x - 1111 111x).
B.左端の7ビットは予約されています（0000 000x -1111 111x）。
Group protocol components each contain a collection of related singular components. In particular, they associate Member Data, Weight Entry, or Member State Instance components to a particular Group Data component. In these cases, the particular "Group of x" component will be immediately followed by the Group Data component. The Group Data component will be immediately followed by any number of singular components the group contains. In figures listed in this document, a component type with an asterisk denotes a component that is repeated a number of times.
グループプロトコルコンポーネントには、それぞれ関連する特異コンポーネントのコレクションが含まれています。特に、メンバーデータ、重量入力、またはメンバー州インスタンスコンポーネントを特定のグループデータコンポーネントに関連付けます。これらの場合、特定の「Xのグループ」コンポーネントの後に、グループデータコンポーネントがすぐに続きます。グループデータコンポーネントの後に、グループに含まれる任意の数の特異コンポーネントがすぐに続きます。このドキュメントにリストされている図では、アスタリスクを備えたコンポーネントタイプは、何度も繰り返されるコンポーネントを示します。
The "group of member data" component describes a particular group of members and is used in the registration message components.
「メンバーデータのグループ」コンポーネントは、特定のメンバーグループを記述し、登録メッセージコンポーネントで使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group of Member Data (0x4010) | Size of GroupOfMemberData TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Group Data TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. *Array of Member Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9
図9
o Member Count: The number of Member Data Components immediately following the Group Data structure.
o メンバーカウント：グループデータ構造の直後のメンバーデータコンポーネントの数。
o Array of Member Data Components: There will be as many Member Data TLVs as Member Count has specified. A load balancer/scheduler would use these components to pass information that would enable the Group Workload Manager to identify the members to associate with this Group Name. The Member Data Component was described in Section 5.1. In DeRegistration messages, the Member Count may be set to 0 to indicate all members of a particular group.
o メンバーデータコンポーネントの配列：メンバーカウントが指定したのと同じくらい多くのメンバーデータTLVがあります。ロードバランサー/スケジューラは、これらのコンポーネントを使用して、グループワークロードマネージャーがメンバーを特定できるようにする情報を渡します。メンバーデータコンポーネントは、セクション5.1で説明されています。解雇メッセージでは、メンバーカウントを0に設定して、特定のグループのすべてのメンバーを示すことができます。
The "Group of Weight Data" Component is used by the get and send weight messages to create a list of Weight Entry Components for a particular group.
「Weight Dataのグループ」コンポーネントは、GETおよびWeightメッセージを送信して、特定のグループの重量入力コンポーネントのリストを作成します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Group Weight Entry Type(0x4011)| Size of GroupOfWeightEntry TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight Entry Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Group Data TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. *Array of Weight Entry Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10
図10
o Weight Entry Count: The number of Member Data / Weight Entry combinations to follow the Group Data TLV.
o 重量入力カウント：グループデータTLVに従うためのメンバーデータ /重量入力の組み合わせの数。
o Array of Weight Entry Data TLVs: There will be as many [Member Data / Weight Entry] TLVs as Weight Entry Count has specified. Each Weight Entry component is preceded by its corresponding Member Data component as explained in Section 5.3. This Member Data / Weight Entry data combination will repeat to form as many Weight Entry items as the Weight Entry Count specifies.
o 重量入力データTLVの配列：重量入力カウントと同じくらい多くの[メンバーデータ /重量入力] TLVがあります。各重量入力コンポーネントの前には、セクション5.3で説明されているように、対応するメンバーデータコンポーネントがあります。このメンバーデータ /重量入力データの組み合わせは、重量入力カウントが指定するのと同じくらい多くの重量入力項目を形成するために繰り返されます。
The "group of member state data" component describes a particular set of members and their corresponding state fields used in the Set Member State messages.
「メンバーデータグループのグループ」コンポーネントは、特定のメンバーのセットと、セットメンバー州のメッセージで使用される対応する州フィールドを記述します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Group Weight Entry Type(0x4011)| Size of GroupOfWeightEntry TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member State Instance Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Group Data TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. *Array of Member State Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11
図11
o Member State Instance Count: The number of Member Data / Member State Instance combinations following the Group Data component.
o 加盟国インスタンスカウント：グループデータコンポーネントに続くメンバーデータ /メンバー州インスタンスの組み合わせの数。
o Array of Member State Data Components: Each Member State Instance component is immediately preceded by its corresponding Member Data component as explained in Section 5.4. This Member Data / Member State Instance combination will repeat to form as many Member State items as the Member State Instance Count specifies.
o 加盟国のデータコンポーネントの配列：各メンバー州インスタンスコンポーネントの前に、セクション5.4で説明されているように、対応するメンバーデータコンポーネントがすぐに行われます。このメンバーデータ /メンバーステートインスタンスの組み合わせは、加盟国インスタンスカウントが指定するのと同じくらい多くの加盟国アイテムを形成するために繰り返されます。
SASP messages are a collection of TLVs (Type, Length, and Value components). The header has no information as to what type of message it is part of; the purpose-specific information is in the message component. This format could facilitate placing more than one message component in a single message; however, this use of multiple message components is not supported in every GWM and could produce indeterminate behavior. Similar to the other protocol components, when a message component needs to involve other components, the additional components immediately follow the message component.
SASPメッセージは、TLV（タイプ、長さ、および値コンポーネント）のコレクションです。ヘッダーには、どのタイプのメッセージがその一部であるかについての情報がありません。目的固有の情報はメッセージコンポーネントにあります。この形式は、単一のメッセージに複数のメッセージコンポーネントを配置することを容易にする可能性があります。ただし、この複数のメッセージコンポーネントの使用はすべてのGWMでサポートされておらず、不確定な動作を生成する可能性があります。他のプロトコルコンポーネントと同様に、メッセージコンポーネントが他のコンポーネントを含む必要がある場合、追加のコンポーネントはすぐにメッセージコンポーネントに従います。
All SASP requests sent to the GWM will be acknowledged with a reply. The reply contains information requested as well as a single-byte response code describing the success of the request. SASP defines some general response codes in the range of 0x00 - 0x3F that may be used regardless of the response message type. However, some request types may cause specific error conditions not covered by the general response codes. The response code range of 0x40 - 0xFF is used for these message-specific response codes. Any given SASP response will only contain one response code (depending on the error type). This section explains the format and purpose of specific SASP messages.
GWMに送信されたすべてのSASPリクエストは、返信で承認されます。返信には、要求された情報と、リクエストの成功を説明するシングルバイト応答コードが含まれています。SASPは、応答メッセージタイプに関係なく使用できる0x00-0x3Fの範囲のいくつかの一般的な応答コードを定義します。ただし、一部の要求タイプは、一般的な応答コードでカバーされていない特定のエラー条件を引き起こす場合があります。これらのメッセージ固有の応答コードには、0x40-0xffの応答コード範囲が使用されます。特定のSASP応答には、1つの応答コードのみが含まれます（エラータイプに応じて）。このセクションでは、特定のSASPメッセージの形式と目的について説明します。
This exchange happens between the load balancer/scheduler and the Group Workload Manager as well as between the Group Workload Manager and the member to register the members in a group specified by Group Name. Applications are identified with an IP address, Protocol, and Port. Systems are identified only with an IP Address (Port = 0x0000 and Protocol = 0x00). All members in a group have equivalent functionality, so the Group Workload Manager can direct routers, load balancers, and schedulers to any member in the group. Even though registrations can come from either the load balancer/scheduler or the actual member, member-initiated registrations will only be considered if the Trust flag is set while the state of the load balancer/scheduler is set.
この交換は、ロードバランサー/スケジューラとグループワークロードマネージャーの間、およびグループワークロードマネージャーとメンバーの間で行われ、グループ名で指定されたグループにメンバーを登録します。アプリケーションは、IPアドレス、プロトコル、およびポートで識別されます。システムは、IPアドレス（port = 0x0000およびプロトコル= 0x00）でのみ識別されます。グループのすべてのメンバーは同等の機能を備えているため、グループワークロードマネージャーは、グループ内のメンバーにルーター、ロードバランサー、スケジューラーを監督できます。登録はロードバランサー/スケジューラまたは実際のメンバーのいずれかからのものですが、メンバーが開始した登録は、ロードバランサー/スケジューラの状態が設定されている間に信頼フラグが設定されている場合にのみ考慮されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Req. Type(0x1010)| Size of Registration Req. TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flag Field | Group of Member Data Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. *Array of Group of Member Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*There will be as many Group of Member Data Components as "Group of Member Data Count" has specified.
*「メンバーデータカウントのグループ」が指定したのと同じくらい多くのメンバーデータコンポーネントがあります。
Figure 12
図12
o Flag Field
o フラグフィールド
A. Load Balancer Flag
A.ロードバランサーフラグ
+ xxxx xxx1 The entity sending this message is the load balancer.
+ xxxx xxx1このメッセージを送信するエンティティはロードバランサーです。
+ xxxx xxx0 The entity sending this message is an Application.
+ xxxx xxx0このメッセージを送信するエンティティはアプリケーションです。
B. Leftmost seven bits are reserved (0000 000x - 1111 111x).
B.左端の7ビットは予約されています（0000 000x -1111 111x）。
o Group of Member Data Count: The number of "Group of Member Data" components immediately following the Registration Request component.
o メンバーデータカウントのグループ：登録要求コンポーネントの直後の「メンバーデータグループ」コンポーネントの数。
o Array of Group of Member Data Components: Each "Group of Member Data" component is immediately followed by Group Data Components and its Member Data components (as described in Section 6.1). In the case where several of these "Group of Member Data" components may be present, the second "Group of Member Data" component only appears after all of the internal components that are referred to by the first "Group of Member Data" component are listed. The format is the same for all subsequent "Group of Member Data" components in the message.
o メンバーデータコンポーネントのグループの配列：各「メンバーデータのグループ」コンポーネントの後に、グループデータコンポーネントとそのメンバーデータコンポーネント（セクション6.1で説明されているように）が続きます。これらの「メンバーデータのグループ」コンポーネントのいくつかが存在する場合、2番目の「メンバーデータのグループ」コンポーネントは、最初の「メンバーデータのグループ」コンポーネントによって参照されるすべての内部コンポーネントの後にのみ表示されます。リストされています。この形式は、メッセージ内の後続のすべての「メンバーデータグループ」コンポーネントで同じです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Registration Reply Type(0x1015)| Size of Registration Reply TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code |
+-+-+-+-+-+-+-+-+
Figure 13
図13
o General SASP return codes (0x00 - 0x3F)
o 一般的なSASPリターンコード（0x00-0x3f）
* 0x00 Successful
* 0x00成功
* 0x10 Message not understood
* 0x10メッセージは理解されていません
* 0x11 GWM will not accept this message from the sender. Reasons for this include the following: a. The message was not sent by a LB and trust flag is off b. LB attempted to address members of a different LB in the message c. Vendor specific criteria for this message type were not met.
* 0x11 GWMは、送信者からのこのメッセージを受け入れません。この理由には、以下が含まれます。メッセージはLBによって送信されず、信頼フラグはbです。LBは、メッセージの異なるLBのメンバーに対処しようとしましたc。このメッセージタイプのベンダー固有の基準は満たされていません。
o Message-Specific return codes (0x40 - 0xFF)
o メッセージ固有の返信コード（0x40-0xff）
* 0x40 Member already registered
* 0x40メンバーはすでに登録されています
* 0x44 Duplicate Member in Request
* 0x44リクエストで複製メンバー
* 0x45 Invalid Group (determined by the GWM)
* 0x45無効なグループ（GWMによって決定）
* 0x50 Invalid Group Name Size (size == 0)
* 0x51 Invalid LB UID Size (size == 0 or > max)
* 0x61 Member is registering itself, but LB hasn't yet contacted the GWM. This registration will not be processed.
* 0x61メンバーはそれ自体を登録していますが、LBはまだGWMに連絡していません。この登録は処理されません。
**The Invalid Group error return code refers to the LB or member attempting to form a group that the GWM considers invalid. For example, some GWM vendors may not support the registration of both System and Application members in the same group. To determine what can cause a GWM to return this error code, the vendor's documentation must be consulted.
**無効なグループエラーリターンコードは、GWMが無効と見なすグループを形成しようとするLBまたはメンバーを指します。たとえば、一部のGWMベンダーは、同じグループのシステムメンバーとアプリケーションメンバーの両方の登録をサポートできない場合があります。GWMがこのエラーコードを返す原因を判断するには、ベンダーのドキュメントを参照する必要があります。
This exchange happens between the load balancer/scheduler and the Group Workload Manager as well as between the Group Workload Manager and the Member to deregister members from a group specified by Group Name with the Group Workload Manager. Even though deregistrations can come from either the load balancer/scheduler or the actual member, member-initiated deregistrations will only be considered if the Trust flag is set with a Set LB State message.
この交換は、ロードバランサー/スケジューラとグループワークロードマネージャーの間、およびグループワークロードマネージャーとグループワークロードマネージャーのグループ名で指定されたグループの登録メンバーとの間で行われます。規制緩和は、ロードバランサー/スケジューラまたは実際のメンバーのいずれかから来る可能性がありますが、メンバーが開始した規制崩壊は、SET LB StateメッセージでTrustフラグが設定されている場合にのみ考慮されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DeRegistration Req.Type(0x1020)|Size of DeRegistration Req. TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flag Field | Reason | Group of Member Data Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. *Array of Group of Member Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*There will be as many Group of Member Data Components as "Group of Member Data Count" has specified.
*「メンバーデータカウントのグループ」が指定したのと同じくらい多くのメンバーデータコンポーネントがあります。
Figure 14
図14
o Flag Field
o フラグフィールド
A. Load Balancer Flag
A.ロードバランサーフラグ
+ xxxx xxx1 The entity sending this message is the load balancer.
+ xxxx xxx1このメッセージを送信するエンティティはロードバランサーです。
+ xxxx xxx0 The entity sending this message is an Application.
+ xxxx xxx0このメッセージを送信するエンティティはアプリケーションです。
B. Leftmost seven bits are reserved (0000 000x - 1111 111x).
B.左端の7ビットは予約されています（0000 000x -1111 111x）。
o Reason: Byte describing the reason for deregistering the group or instance.
o 理由：グループまたはインスタンスを登録する理由を説明するBYTE。
A. SASP-defined Reason Codes (0x00-0x7F)
A. SASP定義の理由コード（0x00-0x7F）
+ 0x00 No reason given.
+ 0x00理由が与えられません。
+ 0x01 Learned and Purposeful, i.e., a human has deconfigured this member from the load balancer configuration.
+ 0x01学習と意図的な、つまり、人間はこのメンバーをロードバランサーの構成からデコンに設定しました。
+ 0x80-0xFF Open for vendor specific deregistration reason codes.
+ 0x80-0xffベンダー固有の規制緩和理由コードのために開いています。
o Group of Member Data Count: The number of "Group of Member Data" components immediately following the DeRegistration Request component.
o メンバーデータカウントのグループ：登録要求コンポーネントの直後の「メンバーデータグループ」コンポーネントの数。
o Array of Group of Member Data Components: Each "Group of Member Data" component is immediately followed by Group Data Components and its Member Data components (as described in Section 6.1). In this case, where several of these "Group of Member Data" components may be present, the second "Group of Member Data" component only appears after all of the internal components that are referred to by the first "Group of Member Data" component are listed. The format is the same for all subsequent "Group of Member Data" components in the message.
o メンバーデータコンポーネントのグループの配列：各「メンバーデータのグループ」コンポーネントの後に、グループデータコンポーネントとそのメンバーデータコンポーネント（セクション6.1で説明されているように）が続きます。この場合、これらの「メンバーデータのグループ」コンポーネントのいくつかが存在する可能性がある場合、2番目の「メンバーデータのグループ」コンポーネントは、最初の「メンバーデータグループ」コンポーネントによって参照されるすべての内部コンポーネントの後にのみ表示されます。リストされています。この形式は、メッセージ内の後続のすべての「メンバーデータグループ」コンポーネントで同じです。
** If Member Count equals zero in the Group of Member Data component, the Group Workload Manager will deregister the entire group.
**メンバーカウントがメンバーデータコンポーネントのグループでゼロに等しい場合、グループワークロードマネージャーはグループ全体を登録します。
** Recall that the Group Data Component contains both a Unique LB Identifier field and a Group Name field. If the Group Data component has no Group Name (GroupData's Group Name Length==0), the Group Workload Manager will deregister all groups associated with this load balancer.
**グループデータコンポーネントには、一意のLB識別子フィールドとグループ名フィールドの両方が含まれていることを思い出してください。グループデータコンポーネントにグループ名がない場合（GroupDataのGroup Name Length == 0）、グループワークロードマネージャーは、このロードバランサーに関連付けられているすべてのグループを登録します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DeReg. Reply Type(0x1025) | Size of DeReg. Reply TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code |
+-+-+-+-+-+-+-+-+
Figure 15
図15
o Return Code: A byte return code indicating the status of action taken.
o 返品コード：実行されたアクションのステータスを示すバイトリターンコード。
A. General SASP return codes (0x00 - 0x3F)
A.一般的なSASPリターンコード（0x00-0x3f）
+ 0x00 Successful
+ 0x00成功
+ 0x10 Message not understood
+ 0x10メッセージは理解されていません
+ 0x11 GWM will not accept this message from the sender. Reasons for this include the following: a. The message was not sent by a LB and trust flag is off b. LB attempted to address members of a different LB in the message c. Vendor specific criteria for this message type were not met.
+ 0x11 GWMは、送信者からのこのメッセージを受け入れません。この理由には、以下が含まれます。メッセージはLBによって送信されず、信頼フラグはbです。LBは、メッセージの異なるLBのメンバーに対処しようとしましたc。このメッセージタイプのベンダー固有の基準は満たされていません。
B. Message-Specific return codes (0x40 - 0xFF)
B.メッセージ固有の返信コード（0x40-0xff）
+ 0x41 Application or System not registered
+ 0x41アプリケーションまたはシステムが登録されていません
+ 0x42 Unknown Group Name
+ 0x42不明なグループ名
+ 0x43 Unknown LB UID
+ 0x43不明なlb uid
+ 0x44 Duplicate Member in Request
+ 0x44リクエストで複製メンバー
+ 0x46 Duplicate Group in Request (for remove all members/groups requests)
+ 0x46リクエストの複製グループ（すべてのメンバー/グループリクエストを削除するため）
+ 0x51 Invalid LB UID Size (size == 0 or > max)
+ 0x61 Member is deregistering itself, but LB hasn't yet contacted the GWM. This deregistration will not be processed.
+ 0x61メンバーは自らを登録していますが、LBはまだGWMに連絡していません。この登録は処理されません。
This exchange happens between the load balancer/scheduler and the Group Workload Manager to get weights for the groups specified in the list of GroupData objects. In the case of application load balancing (balancing workloads between applications with the same functionality), the load balancer would call the Group Workload Manager every Interval (parameter returned by the Group Workload Manager below) to get an array of weights and associated members (e.g., Application1 20, SecondCopyOfApplication 30, ThirdCopyOfApplication 5). The load balancer then uses these weights to determine the fashion in which work will be sent to each of the members. For example, in the case of weighted round robin, the load balancer/scheduler would then send a request to Application1, the next to SecondCopyOfApplication, and the next to ThirdCopyOfApplication. After 15 requests, the load balancer/scheduler would only send work to Application1 and SecondCopyOfApplication. After an additional 30 requests, the load balancer/scheduler would only send requests to SecondCopyofApplication. After another 10 requests, the load balancer/scheduler product would start over using the weights of 20, 30, and 5 again; or if the Interval number of seconds have passed, the load balancer/scheduler would get a new set of weights.
この交換は、Load Balancer/SchedulerとGroup Workload Managerの間で行われ、GroupDataオブジェクトのリストで指定されたグループの重みを取得します。アプリケーションロードバランシング（同じ機能を持つアプリケーション間のワークロードのバランス）の場合、ロードバランサーはグループワークロードマネージャーにすべてのインターバル（以下のグループワークロードマネージャーが返したパラメーター）を呼び出して、重量と関連メンバーの配列を取得します。、Application1 20、SecondCopyopApplication 30、ThirdCopyopApplication 5）。次に、ロードバランサーはこれらのウェイトを使用して、各メンバーに作業が送信されるファッションを決定します。たとえば、重み付けされたラウンドロビンの場合、ロードバランサー/スケジューラは、application1にリクエストを送信します1、次の2番目のコピョーパプリケーション、および次の3番目のコピョアオップアプリケーションの次のものです。15回のリクエストの後、ロードバランサー/スケジューラは、Application1およびSecondCopyofApplicationに作業のみを送信します。追加の30のリクエストの後、ロードバランサー/スケジューラはリクエストのみをSecondCopyopApplicationに送信します。さらに10回のリクエストの後、ロードバランサー/スケジューラ製品は、再び20、30、および5の重量を使用して開始します。または、間隔数秒が経過した場合、ロードバランサー/スケジューラは新しいウェイトセットを取得します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Get Weights Req. Type(0x1030) | Size of Get Weights Req. TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Data Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. *Array of Group Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*There will be as many Group Data Components as "Group Data Count" has specified.
*「グループデータカウント」が指定したのと同じくらい多くのグループデータコンポーネントがあります。
Figure 16
図16
o Group Data Count: The number of "Group Data" components immediately following the Get Weights Request TLV.
o グループデータカウント：GETウェイトの直後の「グループデータ」コンポーネントの数は、TLVを要求します。
o Array of Group Data Components: This array of Group Data Components lists the groups for which the load balancer wants to get weights.
o 一連のグループデータコンポーネント：この一連のグループデータコンポーネントには、ロードバランサーがウェイトを取得したいグループがリストされています。
** If there is no group name in the Group Data structure of the Get Weights Request, the load balancer is requesting weights for all groups registered for the load balancer.
** Get Weightsリクエストのグループデータ構造にグループ名がない場合、ロードバランサーはロードバランサーに登録されたすべてのグループのウェイトを要求しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Get Weights Reply Type(0x1035)| Size of Get Weights Reply TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Interval | Group of Weight
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Entry Data Count| |
+-+-+-+-+-+-+-+-+ +
. .
. *Group of Weight Entry Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* There will be as many Group of Weight Entry Data Components as "Group of Weight Entry Data Count" has specified.
* 「重量入力データカウントのグループ」が指定したのと同じくらい多くの重量入力データコンポーネントがあります。
Figure 17
図17
o Return Code: A byte return code indicating the status of action taken.
o 返品コード：実行されたアクションのステータスを示すバイトリターンコード。
A. General SASP return codes (0x00 - 0x3F)
A.一般的なSASPリターンコード（0x00-0x3f）
+ 0x00 Successful
+ 0x00成功
+ 0x10 Message not understood
+ 0x10メッセージは理解されていません
+ 0x11 GWM will not accept this message from the sender. Reasons for this include the following: a. LB attempted to address members of a different LB in the message b. Vendor specific criteria for this message type were not met.
+ 0x11 GWMは、送信者からのこのメッセージを受け入れません。この理由には、以下が含まれます。LBは、メッセージの異なるLBのメンバーに対処しようとしましたb。このメッセージタイプのベンダー固有の基準は満たされていません。
B. Message-Specific return codes (0x40 - 0xFF)
B.メッセージ固有の返信コード（0x40-0xff）
+ 0x42 Unknown Group Name
+ 0x42不明なグループ名
+ 0x43 Unknown LB UID
+ 0x43不明なlb uid
+ 0x46 Duplicate Group in Request
+ 0x46リクエストの複製グループ
+ 0x51 Invalid LB uid Size (size == 0 or > max)
o Interval: These two bytes indicate a recommended polling interval for the load balancer to use. The Group Workload Manager is stating that any polling interval smaller than the suggested interval would probably retrieve values before they have had a chance to change.
o 間隔：これらの2つのバイトは、ロードバランサーが使用する推奨ポーリング間隔を示しています。グループワークロードマネージャーは、推奨される間隔よりも小さいポーリング間隔は、変更する機会がある前におそらく値を取得すると述べています。
o Group of Weight Entry Data Components: Each "Group of Weight Data" component is immediately followed by Group Data Components and its Weight Entry Data components (as described in Section 6.2). In this case, where several "Group of Weight Data" components may be present, the second "Group of Weight Data" component only appears after all of the internal components that are referred to by the first "Group of Weight Data" component are listed. The format is the same for all subsequent "Group of Weight Data" components in the message.
o 重量入力データコンポーネントのグループ：各「重量データのグループ」コンポーネントの後に、グループデータコンポーネントとその重量入力データコンポーネントがすぐに続きます（セクション6.2で説明されています）。この場合、いくつかの「重量データのグループ」コンポーネントが存在する場合がある場合、2番目の「重量データのグループ」コンポーネントは、最初の「重量データグループ」コンポーネントによって参照されるすべての内部コンポーネントの後にのみ表示されます。。この形式は、メッセージ内の後続のすべての「重量データグループ」コンポーネントで同じです。
This exchange happens between the Group Workload Manager and the load balancer/scheduler to send the new weights for the group specified in Group Name. This message is unique in that it is the only message exchange initiated by the Group Workload Manager and the only message that has no reply. In the case of application load balancing (balancing workloads between applications with the same functionality), the Group Workload Manager would message the load balancer at a possibly dynamic interval (chosen by the Group Workload Manager) to send an array of weights and associated members (e.g., Application1 20, SecondCopyOfApplication 30, ThirdCopyOfApplication 5). The load balancer then uses these weights to determine the fashion in which work will be sent to each of the members. For example, in the case of weighted round robin, the load balancer/scheduler would then send a request to Application1, the next to SecondCopyOfApplication, and the next to ThirdCopyOfApplication. After 15 requests, the load balancer/scheduler would only send work to Application1 and SecondCopyOfApplication. After another 30 requests, the load balancer/scheduler would only send requests to SecondCopyofApplication. After an additional 10 requests, the load balancer/scheduler product would start over using the weights of 20, 30, and 5 again, if it has not yet received a new set of weights. The Group Workload Manager only sends this message if the Push flag has been enabled using a Set Load Balancer State message.
この交換は、グループワークロードマネージャーとロードバランサー/スケジューラの間で発生し、グループ名で指定されたグループの新しいウェイトを送信します。このメッセージは、グループワークロードマネージャーによって開始された唯一のメッセージ交換であり、返信がない唯一のメッセージであるという点でユニークです。アプリケーションロードバランス（同じ機能を持つアプリケーション間のワークロードのバランス）の場合、グループワークロードマネージャーは、おそらく動的な間隔（グループワークロードマネージャーが選択）でロードバランサーにメッセージを送信して、重量と関連メンバーの配列を送信します（たとえば、Application1 20、SecondCopyopApplication 30、ThirdCopyopApplication 5）。次に、ロードバランサーはこれらのウェイトを使用して、各メンバーに作業が送信されるファッションを決定します。たとえば、重み付けされたラウンドロビンの場合、ロードバランサー/スケジューラは、application1にリクエストを送信します1、次の2番目のコピョーパプリケーション、および次の3番目のコピョアオップアプリケーションの次のものです。15回のリクエストの後、ロードバランサー/スケジューラは、Application1およびSecondCopyofApplicationに作業のみを送信します。さらに30回のリクエストの後、ロードバランサー/スケジューラはリクエストをSecondCopyopApplicationにのみ送信します。追加の10のリクエストの後、ロードバランサー/スケジューラ製品は、まだ新しいウェイトセットを受け取っていない場合、20、30、および5のウェイトを使用して開始します。グループワークロードマネージャーは、設定されたロードバランサー状態メッセージを使用してプッシュフラグが有効になっている場合にのみこのメッセージを送信します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send Weights Type(0x1040) | Size of Send Weights TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group of Weight Data Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. *Group of Weight Entry Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* There will be as many Group of Weight Entry Data Components as "Group of Weight Data Count" has specified.
* 「重量データカウントのグループ」が指定したのと同じくらい多くの重量入力データコンポーネントがあります。
Figure 18
図18
o Group of Weight Entry Data Components: Each "Group of Weight Data" component is immediately followed by Group Data Components and its Weight Entry Data components (as described in Section 6.2). In this case, where several "Group of Weight Data" components may be present, the second "Group of Weight Data" component only appears after all of the internal components that are referred to by the first "Group of Weight Data" component are listed. The format is the same for all subsequent "Group of Weight Data" components in the message.
o 重量入力データコンポーネントのグループ：各「重量データのグループ」コンポーネントの後に、グループデータコンポーネントとその重量入力データコンポーネントがすぐに続きます（セクション6.2で説明されています）。この場合、いくつかの「重量データのグループ」コンポーネントが存在する場合がある場合、2番目の「重量データのグループ」コンポーネントは、最初の「重量データグループ」コンポーネントによって参照されるすべての内部コンポーネントの後にのみ表示されます。。この形式は、メッセージ内の後続のすべての「重量データグループ」コンポーネントで同じです。
This is a special exchange that can take place between the load balancer and the Group Workload Manager or between the Member and the Group Workload Manager to pass information about the state of the member including placing the member in quiesced or non-quiesced states. In particular, the load balancer/scheduler can use this message to quiesce a set of members. Members can also use this message to quiesce themselves as well as to pass certain state information to the load balancer/scheduler that is opaque to the Group Workload Manager. This opaque state information is passed to the load balancer/scheduler with the weights during get and send weight messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SetMemberState Req.Type(0x1060)|Size of SetMemberState Req. TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flag Field | Group of MemberStateData Count| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. *Array of Group of Member State Data Components .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*There will be as many Group of Member State Data Components as "Group of Member State Data Count" has specified.
*「加盟国のデータカウントのグループ」が指定しているのと同じくらい多くの加盟国のデータコンポーネントがあります。
Figure 19
図19
o Flag Field
o フラグフィールド
A. Load Balancer Flag
A.ロードバランサーフラグ
+ xxxx xxx1 The entity sending this message is the load balancer.
+ xxxx xxx1このメッセージを送信するエンティティはロードバランサーです。
+ xxxx xxx0 The entity sending this message is an Application.
+ xxxx xxx0このメッセージを送信するエンティティはアプリケーションです。
B. Leftmost seven bits are reserved (0000 000x - 1111 111x).
B.左端の7ビットは予約されています（0000 000x -1111 111x）。
o Group of Member State Data Count: The number of "Group of Member State Data" components immediately following the Set Member State Request TLV.
o 加盟国のデータカウントのグループ：設定された加盟国リクエストTLVの直後の「加盟国データグループ」コンポーネントの数。
o Array of Group of Member Data Components: Each "Group of Member State Data" component is immediately followed by Group Data Components and its Member State Instance components (as described in Section 6.3). In the case where several "Group of Member State Data" components may be present, the second "Group of Member State Data" component only appears after all of the internal components that are referred to by the first "Group of Member State Data" component are listed. The format is the same for all subsequent "Group of Member State Data" components in the message.
o メンバーデータコンポーネントのグループの配列：各「メンバーデータのグループ」コンポーネントの後に、グループデータコンポーネントとそのメンバー州インスタンスコンポーネントがすぐに続きます（セクション6.3で説明されています）。いくつかの「加盟国データのグループ」コンポーネントが存在する場合、2番目の「メンバーデータのグループ」コンポーネントは、最初の「メンバーデータグループのグループ」コンポーネントによって参照されるすべての内部コンポーネントの後にのみ表示されます。リストされています。この形式は、メッセージ内のすべての後続の「メンバーデータグループ」コンポーネントで同じです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set Member State Reply(0x1025)|Size of SetMemberStateReply TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code |
+-+-+-+-+-+-+-+-+
Figure 20
図20
o Return Code: A byte return code indicating the status of action taken.
o 返品コード：実行されたアクションのステータスを示すバイトリターンコード。
A. General SASP return codes (0x00 - 0x3F)
A.一般的なSASPリターンコード（0x00-0x3f）
+ 0x00 Successful
+ 0x00成功
+ 0x10 Message not understood
+ 0x10メッセージは理解されていません
+ 0x11 GWM will not accept this message from the sender. Reasons for this include the following: a. The message was not sent by a LB and trust flag is off b. LB attempted to address members of a different LB in the message c. Vendor specific criteria for this message type were not met.
+ 0x11 GWMは、送信者からのこのメッセージを受け入れません。この理由には、以下が含まれます。メッセージはLBによって送信されず、信頼フラグはbです。LBは、メッセージの異なるLBのメンバーに対処しようとしましたc。このメッセージタイプのベンダー固有の基準は満たされていません。
B. Message-Specific return codes (0x40 - 0xFF)
B.メッセージ固有の返信コード（0x40-0xff）
+ 0x41 Application or System not registered
+ 0x41アプリケーションまたはシステムが登録されていません
+ 0x42 Unknown Group Name
+ 0x42不明なグループ名
+ 0x43 Unknown LB UID
+ 0x43不明なlb uid
+ 0x44 Duplicate Member in Request
+ 0x44リクエストで複製メンバー
+ 0x46 Duplicate Group in Request
+ 0x46リクエストの複製グループ
+ 0x50 Invalid Group Name Size (size == 0)
+ 0x51 Invalid LB UID Size (size == 0 or > than max)
+ 0x61 Member is setting state for itself, but LB hasn't yet contacted the GWM. This request will not be processed.
+ 0x61メンバーはそれ自体の状態を設定していますが、LBはまだGWMに連絡していません。このリクエストは処理されません。
This is an exchange that can take place between the load balancer and the Group Workload Manager to pass information about the state (and partial configuration) of the load balancer.
これは、ロードバランサーとグループワークロードマネージャーの間で行われる交換で、ロードバランサーの状態（および部分的な構成）に関する情報を渡すことができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Set LB State Req. Type (0x1050)| Size of Set LB State Req. TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB UID Length | |
+-+-+-+-+-+-+-+-+ +
. .
. LB UID .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Health | LB Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21
図21
o LB UID Length: one-byte length field describing the size of the following LB UID.
o LB UID長：次のLB UIDのサイズを記述する1バイトの長さフィールド。
o LB UID: This should be the same unique identifier given when registering group members for this particular load balancer.
o LB UID：これは、この特定のロードバランサーにグループメンバーを登録するときに与えられるのと同じ一意の識別子である必要があります。
o LB Health: This field gives the load balancer a chance to pass in a metric describing its own health or state.
o LB Health：このフィールドは、ロードバランサーに自分の健康または状態を説明するメトリックを通過する機会を与えます。
0x00 - 0x7F Least Healthy - Most Healthy
0x00-0x7f健康 - 最も健康
0x80 - 0xFF Reserved
0x80-0xff予約
o LB Flags:
o LBフラグ：
A. Push Flag
A.フラグを押します
+ xxxx xxx1 The load balancer should receive weights through the Send Weights message (GWM pushes weights to load balancer). Even if this flag is set, the GWM must still respond accordingly to any Get Weights messages from the load balancer.
+ xxxx xxx1ロードバランサーは、送信ウェイトメッセージを介して重量を受け取る必要があります（GWMは重量を押してロードバランサーにプッシュします）。このフラグが設定されていても、GWMはロードバランサーからのWeightsメッセージを取得することにそれに応じて応答する必要があります。
+ xxxx xxx0 The load balancer will send a Get Weights message to get the new weights. This is the default behavior. (load balancer pulls weights from GWM).
+ xxxx xxx0ロードバランサーは、新しいウェイトを取得するためにGet Weightsメッセージを送信します。これがデフォルトの動作です。（Load BalancerはGWMからウェイトを引きます）。
B. Trust Flag
B.信頼フラグ
+ xxxx xx1x Trust any member-initiated registration, deregistration, or set state message. Immediately reflect the registration, deregistration, or new state in the weights sent.
+ xxxx xx1xメンバーが開始した登録、登録、または状態メッセージの設定を信頼してください。送信された重みの登録、登録、または新しい状態をすぐに反映します。
+ xxxx xx0x Do not trust any member-initiated registration, deregistration, or set state message. Registration, Deregistration, and State Setting of members can only occur from the load balancer. Discard any member-initiated registration, deregistration, or set state message. This is the default behavior.
+ XXXX XX0Xは、メンバーが開始した登録、規制緩和、または状態メッセージを設定することを信頼していません。メンバーの登録、規制緩和、および状態設定は、ロードバランサーからのみ発生できます。メンバーが開始した登録、登録、または状態メッセージを設定します。これがデフォルトの動作です。
C. No Change / No Send Flag
C.変更なし /送信フラグ
+ xxxx x1xx The GWM must not include members whose weights and state (i.e., contact and quiesce flags) have not changed since they were last sent.
+ XXXX X1XX GWMには、重みと状態（つまり、接触フラグとQuiesceフラグ）が最後に送られてから変更されていないメンバーを含めてはなりません。
+ xxxx x0xx The GWM must include the weights of all group members when sending the weights to this load balancer (including members whose weights and state have not changed). This is the default behavior.
+ XXXX X0XX GWMには、このロードバランサー（重みと状態が変更されていないメンバーを含むメンバーを含む）を送信する際に、すべてのグループメンバーの重みを含める必要があります。これがデフォルトの動作です。
D. Leftmost five bits are reserved (0000 0xxx - 1111 1xxx).
D.左端の5ビットは予約されています（0000 0xxx -1111 1xxx）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SASP Header TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set LB State Reply (0x1025) | Size of Set LB State Reply TLV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code |
+-+-+-+-+-+-+-+-+
Figure 22
図22
o Return Code: A byte return code indicating the status of action taken.
o 返品コード：実行されたアクションのステータスを示すバイトリターンコード。
A. General SASP return codes (0x00 - 0x3F)
A.一般的なSASPリターンコード（0x00-0x3f）
+ 0x00 Successful
+ 0x00成功
+ 0x10 Message not understood
+ 0x10メッセージは理解されていません
+ 0x11 GWM will not accept this message from the sender. Reasons for this include the following: a. LB attempted to address the state of a different LB b. Vendor specific criteria for this message type were not met.
+ 0x11 GWMは、送信者からのこのメッセージを受け入れません。この理由には、以下が含まれます。LBは、異なるLB bの状態に対処しようとしました。このメッセージタイプのベンダー固有の基準は満たされていません。
B. Message-Specific return codes (0x40 - 0xFF)
B.メッセージ固有の返信コード（0x40-0xff）
+ 0x51 Invalid LB UID Size (size == 0 or > max)
This section provides an example of the actual SASP message encoding. For this example, we will look at a sample GetWeights Reply in which two webservers are registered to a serverfarm called FARM1. The IP addresses of the two webservers are 10.10.10.1 and 10.10.10.2. Currently the GWM has a weight of 40 for 10.10.10.1 and 20 for 10.10.10.2. The load balancer has a unique Identifier of "LB1" and the message example was sent by the GWM in response to a request (MessageID: 0x32000000) for FARM1's weights.
このセクションでは、実際のSASPメッセージエンコードの例を示します。この例では、2つのWebサーバーがFarm1と呼ばれるサーバーファームに登録されているサンプルGetWeightsの返信を調べます。2つのウェブサーバーのIPアドレスは10.10.10.1および10.10.10.2です。現在、GWMの重量は10.10.10.1で40、10.10.10.2で20です。ロードバランサーには「LB1」の一意の識別子があり、メッセージの例は、Farm1の重量のリクエスト（MessageID：0x3200000000）に応じてGWMによって送信されました。
The TLVs necessary for this message are shown in the following list.
このメッセージに必要なTLVは、次のリストに示されています。
1. SASP Header TLV
1. SASPヘッダーTLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x2010 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x000D |
|-----------|---------|------------|
| | Version | 1 byte | 0x01 |
| |---------|---------|------------|
|V| Mesg Len| 4 bytes | 0x0000 006A|
| |---------|---------|------------|
| | Mesg ID | 4 bytes | 0x3200 0000|
------------------------------------
Figure 23
図23
2. Get Weights Reply TLV
2. ウェイトを取得しますtlvに返信します
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x1035 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x0009 |
|-----------|---------|------------|
| | RetCode | 1 byte | 0x00 |
| |---------|---------|------------|
|V| Interval| 2 bytes | 0x0040 |
| |---------|---------|------------|
| |GWD Count| 2 bytes | 0x0001 |
------------------------------------
*GWD Count = Group of Weight Data Count
Figure 24
図24
3. Group of Weight Data TLV
3. 重量データのグループTLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x4011 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x0006 |
|-----------|---------|------------|
|V| WE Count| 2 bytes | 0x0002 |
------------------------------------
*WE Count = Weight Entry Count
Figure 25
図25
4. Group Data TLV
4. グループデータTLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x3011 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x000E |
|-----------|---------|------------|
| |LBUID len| 1 byte | 0x03 |
| |---------|---------|------------|
| | LBUID | 3 bytes | "LB1" or |
| | | | 0x4C 42 31 |
|V|---------|---------|------------|
| |GroupName| 1 byte | 0x05 |
| | Length | | |
| |---------|---------|------------|
| | Group | | "FARM1" or |
| | Name | 5 bytes | 0x46 41 52 |
| | | | 4D 31 |
------------------------------------
Figure 26
図26
5. Member Data TLV
5. メンバーデータTLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x3010 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x0018 |
|-----------|---------|------------|
| | Protocol| 1 byte | 0x06 |
| |---------|---------|------------|
| | Port | 2 bytes | 0x0050 |
| |---------|---------|------------|
|V| IP |16 bytes | 0x0000 0000|
| | Address | | 0000 0000|
| | | | 0000 0000|
| | | | 0A0A 0A01|
| |---------|---------|------------|
| |Label Len| 1 byte | 0x00 |
| |---------|---------|------------|
| | Label | 0 bytes | |
------------------------------------
Figure 27
図27
6. Weight Entry Data TLV
6. 重量入力データTLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x3012 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x0008 |
|-----------|---------|------------|
| | State | 1 byte | 0x00 |
| |---------|---------|------------|
|V| Flags | 1 byte | 0x0D |
| |---------|---------|------------|
| | Weight | 2 bytes | 0x0028 |
------------------------------------
Figure 28
図28
7. Member Data TLV
7. メンバーデータTLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x3010 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x0018 |
|-----------|---------|------------|
| | Protocol| 1 byte | 0x06 |
| |---------|---------|------------|
| | Port | 2 bytes | 0x0050 |
| |---------|---------|------------|
|V| IP |16 bytes | 0x0000 0000|
| | Address | | 0000 0000|
| | | | 0000 0000|
| | | | 0A0A 0A02|
| |---------|---------|------------|
| |Label Len| 1 byte | 0x00 |
| |---------|---------|------------|
| | Label | 0 bytes | |
------------------------------------
Figure 29
図29
8. Weight Entry Data TLV
8. 重量入力データTLV
------------------------------------
| | Field | Size | Value |
|-----------|---------|------------|
|T| Type | 2 bytes | 0x3012 |
|-----------|---------|------------|
|L| Length | 2 bytes | 0x0008 |
|-----------|---------|------------|
| | State | 1 byte | 0x00 |
| |---------|---------|------------|
|V| Flags | 1 byte | 0x0D |
| |---------|---------|------------|
| | Weight | 2 bytes | 0x0014 |
------------------------------------
Figure 30
図30
A hex stream representing this same message is below:
この同じメッセージを表す16進ストリームは以下にあります。
20 10 00 0D 01 00 00 00 6A 32 00 00 00 10 35 00 09 00 00 40
20 10 00 0d 01 00 00 00 6a 32 00 00 00 10 35 00 09 00 00 40
00 01 40 11 00 06 00 02 30 11 00 0E 03 4C 42 31 05 46 41 52 4D 31 30 10 00 18 06 00 50 00 00 00 00 00 00 00 00 00 00 00
00 01 40 11 00 06 00 02 30 11 00 0E 03 4C 42 31 05 46 41 52 4D 30 10 10 00 18 06 00 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 0A 0A 0A 01 00 30 12 00 08 00 0D 00 28 30 10 00 18 06 00
00 0A 0A 0A 01 00 30 12 00 08 00 0D 00 28 30 10 00 18 06 00
50 00 00 00 00 00 00 00 00 00 00 00 00 0A 0A 0A 02 00 30 12
50 00 00 00 00 00 00 00 00 00 00 00 00 00 0A 0A 02 00 30 12
00 08 00 0D 00 14
00 08 00 0D 00 14
(106 bytes)
（106バイト）
This section describes the expected general flow of the SASP messages.
このセクションでは、SASPメッセージの予想される一般的な流れについて説明します。
SASP first starts with a connection from an LB to the GWM. This is expected to be a long-running connection and will be used for many messages. After establishing the connection, the LB either registers a group of members or sets a Trust flag to allow the members to register themselves. The Trust flag is set using a Set LB State Request (both message flows are shown below).
SASPは、最初にLBからGWMへの接続から始まります。これは長期にわたる接続であると予想され、多くのメッセージに使用されます。接続を確立した後、LBはメンバーのグループを登録するか、メンバーが自分自身を登録できるように信頼フラグを設定します。Trustフラグは、設定されたLB状態要求を使用して設定されます（両方のメッセージフローを以下に示します）。
Registration from load balancer
ロードバランサーからの登録
------------ Registration Request ------------------
| |----------------------->| |
| Load | | Group Workload |
| Balancer | Registration Reply | Manager |
| |<-----------------------| |
------------ ------------------
Set LB State from load balancer
ロードバランサーからLB状態を設定します
------------ Set LB State Request ------------------
| |----------------------->| |
| Load | | Group Workload |
| Balancer | Set LB State Reply | Manager |
| |<-----------------------| |
------------ ------------------
Figure 31
図31
The connection can start with other requests, but any other request would likely result in an error (unless this connection is a reconnection that has happened a short period of time after the original connection). For example, if the load balancer issues a deregistration request as its first message, it will receive an error because it has not registered any groups.
接続は他のリクエストから始まることができますが、他のリクエストはエラーになる可能性があります（この接続が元の接続後に短時間で発生した再接続でない限り）。たとえば、ロードバランサーが最初のメッセージとして登録要求を発行する場合、グループを登録していないためエラーが表示されます。
The load balancer always drops all state information after a loss of connection and can recover it using a GetWeights message. The establishment of a new connection causes the GWM to assume that the old one is broken. In this case, the GWM will keep all state for the load balancer for a limited time after a detected break. After the limited time has expired, all state for the broken connection will be discarded by the GWM.
ロードバランサーは、接続が失われた後、常にすべての状態情報を削除し、getWeightsメッセージを使用して回復することができます。新しい接続の確立により、GWMは古い接続が壊れていると仮定します。この場合、GWMは、検出された休憩後、限られた時間の間、ロードバランサーのすべての状態を維持します。期間限定が終了した後、壊れた接続のすべての状態はGWMによって破棄されます。
Registration of group members may be done at any time. A load balancer can register anywhere from one group with one member to many groups of many members. The member may also register itself if the Trust flag has been set and it knows the appropriate load balancer information. Registrations will add to groups that already exist, but return errors if any of the registered members already exist.
グループメンバーの登録はいつでも行うことができます。ロードバランサーは、1つのグループから1つのメンバーと一緒に多くのメンバーの多くのグループに登録できます。メンバーは、Trust Flagが設定されている場合、自らを登録することもでき、適切なロードバランサー情報を知っています。登録は既に存在するグループに追加されますが、登録されたメンバーのいずれかがすでに存在する場合はエラーを返します。
In the case of system load balancing, the representation of a member is only the member's IP address with a 0 used as the value for the port and protocol. In the case of application load balancing, the representation of a member is the member's IP address and the Application's port and protocol.
システムロードバランシングの場合、メンバーの表現は、ポートとプロトコルの値として使用される0を持つメンバーのIPアドレスのみです。アプリケーションの負荷分散の場合、メンバーの表現はメンバーのIPアドレスとアプリケーションのポートおよびプロトコルです。
Deregistration of group members may be done at any time. A load balancer can deregister anywhere from one group with one member to many groups of many members. The LB may also deregister entire groups or deregister all of its groups at once. The member may also deregister itself if the Trust flag has been set and it knows the appropriate load balancer information.
グループメンバーの規制緩和はいつでも行われる場合があります。ロードバランサーは、1人のグループを持つ1つのグループから、多くのメンバーの多くのグループに登録することができます。また、LBはグループ全体を登録したり、すべてのグループを一度に登録したりすることがあります。メンバーは、Trustフラグが設定されている場合、登録することもできます。また、適切なロードバランサー情報を知っています。
Once members are registered, the GWM will start the monitoring and weight computation processes to determine weights to be sent back to the load balancer. At any time the load balancer may issue a GetWeights message and ask for the weights for members in a particular group. The LB may also set a flag telling the GWM to send the weights without waiting for the GetWeights message. If this flag is set, the GWM will send the weights at an interval it feels is appropriate (the interval could change depending on the algorithm used and variance of the weights generated).
メンバーが登録されると、GWMは監視および重量計算プロセスを開始し、ロードバランサーに送り返される重みを決定します。いつでもロードバランサーはgetWeightsメッセージを発行し、特定のグループのメンバーのウェイトを尋ねることができます。また、LBは、GetWeightsメッセージを待たずにWeightsを送信するようにGWMに伝えるフラグを設定する場合があります。このフラグが設定されている場合、GWMは適切だと思われる間隔で重みを送信します（使用されるアルゴリズムと生成された重みの分散に応じて間隔は変化する可能性があります）。
At any time the LB or a particular member may quiesce the member through the use of a SetMemberState message. In this case, the member's weight will always be zero, and the quiesce flag will be turned on when sending its weight. Members may also use this message to send an opaque state value that will also be presented when sending weights.
いつでもLBまたは特定のメンバーは、セットメンバーテートメッセージを使用してメンバーをQuiesceすることができます。この場合、メンバーの体重は常にゼロになり、重量を送信するとQuiesceフラグがオンになります。メンバーは、このメッセージを使用して、重みを送信するときに提示される不透明な状態値を送信することもできます。
At any time, the load balancer may choose to send the GWM a SetLBState request to configure its interaction. The message allows the load balancer to set the Push, Trust, and NoChange_NoSend flags. It also allows the load balancer to pass a health value to the GWM to be displayed.
いつでも、ロードバランサーは、その相互作用を構成するためにGWMにsetlbStateリクエストを送信することを選択できます。このメッセージにより、ロードバランサーはプッシュ、信頼、およびnochange_nosendフラグを設定できます。また、ロードバランサーはGWMに健康価値を渡すことができます。
While behaviors in many error conditions will be product specific, the following error cases should have the following expected behavior.
多くのエラー条件での動作は製品固有ですが、次のエラーケースには次の予想される動作が必要です。
Case: The protocol is violated in an unrecoverable manner by either end of the connection.
ケース：プロトコルは、接続のどちらの端でも回収不能な方法で違反されます。
Behavior: Either end of the connection may choose to disconnect to avoid future message synchronization problems. The state kept when disconnected is vendor specific.
動作：接続のいずれかの端は、将来のメッセージの同期の問題を回避するために切断することを選択できます。切断されたときに状態はベンダー固有のものです。
Case: LB or application attempts to connect to the GWM before the GWM is fully up and running.
ケース：LBまたはアプリケーションは、GWMが完全に稼働する前にGWMに接続しようとします。
Behavior: The LB or application should wait at least 20 seconds to retry the connection.
動作：LBまたはアプリケーションは、少なくとも20秒待って接続を再試行する必要があります。
Case: Members attempt to register or deregister themselves before the LB develops the connection with the GWM.
ケース：LBがGWMとの接続を開発する前に、メンバーは自分自身を登録または登録しようとします。
Behavior: In this case, the members would receive a reply with an error code signifying that there is no LB registered with that LB UID.
動作：この場合、メンバーは、そのLB UIDに登録されているLBがないことを示すエラーコードを使用して返信を受け取ります。
Case: Member registers or deregisters for an LB who has not set the Trust flag.
ケース：信頼フラグを設定していないLBのメンバーレジスタまたはデレギスター。
Behavior: GWM will send Member a reply containing an error code.
動作：GWMは、エラーコードを含む返信をメンバーに送信します。
Case: LB asks for weights for a group that doesn't exist.
ケース：LBは、存在しないグループのウェイトを要求します。
Behavior: GWM will send LB a reply containing an error code.
動作：GWMは、エラーコードを含む返信をLBに送信します。
Case: LB or Member attempts to register a member that is already registered in that group.
ケース：LBまたはメンバーは、そのグループに既に登録されているメンバーを登録しようとします。
Behavior: GWM will send sender a reply containing an error code.
動作：GWMは、エラーコードを含む返信を送信者に送信します。
Case: LB or Member attempts to deregister a member or group that doesn't exist.
ケース：LBまたはメンバーは、存在しないメンバーまたはグループを登録しようとします。
Behavior: GWM will send sender a reply containing an error code.
動作：GWMは、エラーコードを含む返信を送信者に送信します。
Case: LB or Member tries to set state for a non-registered server.
ケース：LBまたはメンバーは、非登録サーバーの状態を設定しようとします。
Behavior: GWM will send sender a reply containing an error code.
動作：GWMは、エラーコードを含む返信を送信者に送信します。
Case: LB tries to Get Weights for an unregistered group.
ケース：LBは、未登録のグループのウェイトを取得しようとします。
Behavior: GWM will send LB a reply containing an error code.
動作：GWMは、エラーコードを含む返信をLBに送信します。
Load Group Workload
Balancer Manager
| |
| 1) Registration Request |
|------------------------>|
|<------------------------|
| Registration Reply |
| |
| 2) Set LB State Request |
|------------------------>|
|<------------------------|
| Set LB State Reply |
| |
| 3) Get Weights Request |
|------------------------>|
|<------------------------|
| Get Weights Reply |
| | 4) Set Member State Req. --------
| |<-------------------------|Member|
| |------------------------->| A |
| | Set Member State Reply --------
| |
| | 5) Set Member State Req. --------
| |<-------------------------|Member|
| |------------------------->| C |
| | Set Member State Reply --------
| |
| 6) Get Weights Request |
|------------------------>|
|<------------------------|
| Get Weights Reply |
| |
| | 7) Set Member State Req. --------
| |<-------------------------|Member|
| |------------------------->| C |
| | Set Member State Reply --------
| |
| 8) Get Weights Request |
|------------------------>|
|<------------------------|
| Get Weights Reply |
| |
Figure 32
図32
1. The LB registers Members A, B, and C in a group named GRP1. The GWM replies with no error.
1. LBは、GRP1という名前のグループにメンバーA、B、およびCを登録します。GWMはエラーなしで応答します。
2. The LB turns its trust flag on by issuing a Set LB State message:
2. LBは、セットLB状態メッセージを発行することにより、信頼フラグをオンにします。
LB Health: 0x00 Flags: 0000 0010
LB Health：0x00フラグ：0000 0010
3. The LB sends a Get Weights message for GRP1 and gets the reply:
3. LBはGRP1のGet Weightsメッセージを送信し、返信を取得します。
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x00 0000 1101 20
Member B 0x00 0000 1101 40
Member C 0x00 0000 1101 5
4. Member A sends a Set Member State message with flags:
4. メンバーAは、フラグを使用してセットメンバー州のメッセージを送信します。
Members Opaque State Flags
-------- ------------ ---------
Member A 0x32 0000 0000
5. Member C sends a Set Member State message to quiesce itself with the following flags:
5. メンバーCは、次のフラグを使用して、セットメンバー州のメッセージをQuiesce自身に送信します。
Members Opaque State Flags
-------- ------------ ---------
Member C 0x0A 0000 0001
6. The LB sends the Get Weights message for GRP1 and receives the following:
6. LBはGRP1のGet Weightsメッセージを送信し、以下を受け取ります。
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x32 0000 1101 20
Member B 0x00 0000 1101 40
Member C 0x0A 0000 1111 5
7. Member C sends a Set Member State message to resume (un-quiesce itself) with the following flags:
7. メンバーCは、次のフラグを履歴書（自体を解除する）にセットメンバー州のメッセージを送信します。
Members Opaque State Flags
-------- ------------ ---------
Member C 0x0A 0000 0000
8. The LB sends a Get Weights message for GRP1 and gets the reply:
8. LBはGRP1のGet Weightsメッセージを送信し、返信を取得します。
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x32 0000 1101 20
Member B 0x00 0000 1101 40
Member C 0x0A 0000 1101 5
Load Group Workload
Balancer Manager
| |
| 1) Set LB State Request |
|------------------------>|
|<------------------------|
| Set LB State Reply |
| |
| | 2) Registration Request --------
| |<-------------------------|Member|
| |------------------------->| A |
| | Registration Reply --------
| |
| | 3) Registration Request --------
| |<-------------------------|Member|
| |------------------------->| B |
| | Registration Reply --------
| |
| 4) Send Weights Mesg |
|<------------------------|
| |
| | 5) Registration Request --------
| |<-------------------------|Member|
| |------------------------->| C |
| | Registration Reply --------
| |
| 6) Send Weights Mesg |
|<------------------------|
| |
|7) Deregistration Request|
|------------------------>|
|<------------------------|
| Deregistration Reply |
| |
Figure 39
図39
1. The LB sets its state with the Set LB State message and the following parameters.
1. LBは、設定されたLB状態メッセージと次のパラメーターで状態を設定します。
Health: 0x7F Flags: 0000 0011
健康：0x7fフラグ：0000 0011
2. Member A registers itself for work in GRP1 using the Register message.
2. メンバーAは、レジスタメッセージを使用してGRP1での作業に登録します。
3. Member B registers itself for work in GRP1 using the Register message.
3. メンバーBは、レジスタメッセージを使用してGRP1での作業に登録します。
4. The GWM issues a Send Weights message to the LB.
4. GWMは、LBに送信ウェイトメッセージを発行します。
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x00 0000 1001 20
Member B 0x00 0000 1001 40
5. Member C registers itself for work in GRP1 using the Register message.
5. メンバーCは、レジスタメッセージを使用してGRP1での作業に登録します。
6. The GWM issues a Send Weights message to the LB.
6. GWMは、LBに送信ウェイトメッセージを発行します。
Members Opaque State Flags Weight
-------- ------------ --------- ------
Member A 0x00 0000 1001 20
Member B 0x00 0000 1001 40
Member C 0x00 0000 1001 5
7. LB deregisters GRP1 by using the DeRegister message with the Member Data Count = 0
7. LB Deregisters GRP1メンバーデータカウントで登録メッセージを使用して= 0
o To avoid having a single point of failure at the load balancer, an administrator may choose to have multiple load balancers in his or her environment. SASP provides for the GWM to keep track of multiple load balancers through the use of load balancer unique identifiers (LB UIDs).
o ロードバランサーに単一の障害が発生しないようにするために、管理者は環境に複数のロードバランサーを持つことを選択できます。SASPは、Load Balancerユニークな識別子（LB UID）を使用して複数のロードバランサーを追跡するためにGWMを提供します。
o To avoid having a single point of failure at the GWM or enhance the load balancing strategy by utilizing the strengths of several different GWMs, an administrator may choose to have multiple GWMs in his or her environment. In this case, the load balancer would connect to multiple GWMs and register the same groups with corresponding members. The load balancer may choose to coordinate the recommendations of each GWM by any method it chooses (e.g., statistical combination such as averaging). The coordination of weights from multiple GWMs is product specific and not addressed in this protocol.
o GWMで単一の障害のポイントを持つことを避けたり、いくつかの異なるGWMの強度を利用して負荷分散戦略を強化したりするために、管理者は環境に複数のGWMを使用することを選択できます。この場合、ロードバランサーは複数のGWMに接続し、同じグループを対応するメンバーと登録します。ロードバランサーは、選択した方法（たとえば、平均化などの統計的な組み合わせ）によって、各GWMの推奨事項を調整することを選択できます。複数のGWMからの重みの調整は製品固有であり、このプロトコルでは対処されていません。
SASP is a binary stream expected to be transported over a TCP connection. To secure this protocol, it is expected that implementers of the protocol use a secure mode of transport such as SSL/TLS. Discussions around security concerns have been listed below:
SASPは、TCP接続を介して輸送されると予想されるバイナリストリームです。このプロトコルを保護するために、プロトコルの実装者がSSL/TLSなどの安全な輸送モードを使用することが期待されています。セキュリティの懸念に関する議論は、以下にリストされています。
Security Issue: In insecure environments, if the LB UID becomes known by another system, the other system could initiate a connection and send messages to the GWM causing the GWM to replace the previous (possibly valid) connection for the new (potentially bad) connection.
セキュリティの問題：不安定な環境では、LB UIDが別のシステムで知られるようになった場合、他のシステムは接続を開始し、GWMにメッセージを送信して、GWMが新しい（潜在的に悪い）接続の前（おそらく有効な）接続を置き換える原因となる可能性があります。。
Solution: This may not be a concern if the load balancer and GWM are in protected parts of the network. If the administrator is concerned about this vulnerability, she should use SSL or TLS to provide authentication for the connection. When using SSL or TLS to secure the connection, the administrator SHOULD use both server and client authentication through client and server certificates. The GWM will trust any certificate that is signed by an authority it's been configured to trust.
解決策：これは、ロードバランサーとGWMがネットワークの保護された部分にある場合、懸念事項ではない場合があります。管理者がこの脆弱性を懸念している場合、彼女はSSLまたはTLSを使用して接続の認証を提供する必要があります。SSLまたはTLSを使用して接続を保護する場合、管理者はクライアント証明書とサーバー証明書を介してサーバーとクライアントの両方の認証を使用する必要があります。GWMは、信頼するように構成されている当局によって署名された証明書を信頼します。
Security Issue: In insecure environments, if the load balancer turns the Trust Flag on, any member or other system can send a Registration Message and be included in the serverfarm to receive work. A person with bad intentions and the correct information could exploit this feature and register his own application to receive work. His counterfeit application could capture valuable data from unsuspecting clients as their transactions are sent to his system.
セキュリティの問題：不安定な環境では、ロードバランサーがTrustフラグをオンにした場合、メンバーまたはその他のシステムは登録メッセージを送信し、ServerFarmに含まれて作業を受信できます。悪い意図と正しい情報を持っている人は、この機能を活用し、自分の申請を登録して仕事を受け取ることができます。彼の偽造アプリケーションは、トランザクションが彼のシステムに送信されるため、疑いを持たないクライアントから貴重なデータをキャプチャできます。
Solution: This may not be a concern if the GWM and its members are in protected parts of the network. If the administrator is concerned about this vulnerability, she should use SSL or TLS to provide authentication for the member connections. When using SSL or TLS to authenticate the connection, the administrator would need to explicitly install valid certificates on each component while at the same time establishing the trusted certificates of each component. This would make certain that only those trusted components would be permitted to connect to the GWM.
解決策：GWMとそのメンバーがネットワークの保護された部分にいる場合、これは懸念事項ではないかもしれません。管理者がこの脆弱性を懸念している場合、彼女はSSLまたはTLSを使用してメンバー接続の認証を提供する必要があります。SSLまたはTLSを使用して接続を認証する場合、管理者は各コンポーネントに有効な証明書を明示的にインストールすると同時に、各コンポーネントの信頼できる証明書を確立する必要があります。これにより、これらの信頼できるコンポーネントのみがGWMに接続できることを確認します。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
The author gratefully acknowledges contributions by Mark Albert, David McCowan, John Fenton, Derek Huckaby, Dyan Collins, and Stefano Testa. Mark Albert, David McCowan, John Fenton, Derek Huckaby, Dyan Collins, and Stefano Testa were supported for this work by Cisco Systems Inc.
著者は、マーク・アルバート、デビッド・マコーワン、ジョン・フェントン、デレク・ハッカビー、ダイアン・コリンズ、ステファノ・テスタによる貢献を感謝して認めています。マーク・アルバート、デビッド・マコワン、ジョン・フェントン、デレク・ハッカビー、ダイアン・コリンズ、およびステファノ・テスタは、Cisco Systems Inc.によってこの研究のためにサポートされました。
The author would also like to thank John Arwe, Dave Bostjancic, Brian Carpenter, Donna Dillenberger, Gus Kassimis, and Thomas Narten for their efforts in the creation and refining of this work.
著者はまた、ジョン・アルウェ、デイブ・ボスジャンシック、ブライアン・カーペンター、ドナ・ディレンバーガー、ガス・カシミス、トーマス・ナルテンに、この作品の創造と改良の努力に感謝したいと思います。
Author's Address
著者の連絡先
Alan Bivens IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US
Alan Bivens Ibm T.J.ワトソンリサーチセンター19スカイラインドライブホーソーン、ニューヨーク10532米国
EMail: jbivens@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、その中に記載されている場合を除き、著者はすべての権利を保持します。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。