以下の各章で、Solaris 9 オペレーティング環境におけるサービスロケーションプロトコル (SLP) の構成と配置について説明します。
SLP アーキテクチャと実装について説明します。
SLP 構成と SLPを有効にする方法について説明します。
SLP のエージェントとプロセスを構成する方法について説明します。
SLP のレガシーサービスの通知について説明します。
SLP のステータスコードとメッセージタイプをリストします。
サービスロケーションプロトコル (SLP) は、SLP が使用できるネットワークサービスを検出しそれに対応するための、移植性が高くプラットフォームに依存しないフレームワークを提供します。この章では、SLP のアーキテクチャの概要と、IP イントラネットに対応する SLP の Solaris 9 での実装について説明します。
この節では、SLP の基本的な処理を示し、SLP の管理で使用されるエージェントとプロセスについて説明します。
SLP は、次のサービスを自動的に行い、設定はほとんどあるいはまったく必要ありません。
クライアントアプリケーションがサービスへのアクセスに必要な情報を要求する
プリンタ、ファイルサーバー、ビデオカメラ、HTTP サーバーなどのネットワークのハードウェアデバイスやソフトウェアサーバーにサービスを通知する
主サーバーの障害からの管理された回復
また、SLP の動作を管理、調整するために、必要に応じて次のことを実行できます。
サービスとユーザーを論理グループや機能グループから構成されるスコープに編成する
SLP のロギングを有効にして、ネットワーク上の SLP 動作の監視と障害追跡を行う
SLP のタイミングパラメータを調整して、パフォーマンスの向上とスケーラビリティの拡張を行う
SLP がマルチキャストルーティングに対応していないネットワークに配置されている場合、マルチキャストメッセージの送信や処理を行わないように SLP を構成する
SLP ライブラリは、サービスをネットワークで検出するための情報を、サービスを通知するネットワーク対応のエージェントに与えます。SLP エージェントは、サービスの種類と場所に関する最新情報を保持します。これらのエージェントはプロキシ登録を使用することで、SLP が直接使用できないサービスを通知することもできます。詳細は、第 19 章「レガシーサービスの組み込み」を参照してください。
クライアントアプリケーションは、SLP ライブラリに依頼して、サービスを通知するエージェントに直接要求を出してもらいます。
次の表では、SLP エージェントについて説明します。ここで使用する用語の詳細な定義は、用語集を参照してください。
表 16–1 SLP エージェント
SLP エージェント |
説明 |
|
---|---|---|
ディレクトリエージェント (DA) |
サービスエージェント (SA) が登録する SLP 通知をキャッシュするプロセス。DAは、要求に応じて、サービス通知をユーザーエージェント (UA) に転送する |
|
サービスエージェント (SA) |
サービス通知を配信するためやサービスをディレクトリエージェント (DA) に登録するために、サービスの代理として動作する SLP エージェント |
|
ユーザーエージェント (UA) |
サービス通知情報を取得するために、ユーザーやアプリケーションの代理として動作する SLP エージェント |
|
スコープ |
サービスに対する管理上または論理上のグループ |
|
次の図は、SLP アーキテクチャを実装する、基本的なエージェントおよびプロセスを示しています。図は、SLP のデフォルトの配置を表しています。特別な構成はまったく行われていません。UA と SA の 2 つのエージェントだけが 必要です。SLP フレームワークでは、UA がサービス要求を SA にマルチキャストすることを許可しています。SA は、UA に対して応答をユニキャストします。たとえば、UA がサービス要求メッセージを送信すると、SA はサービス応答メッセージを返します。サービス応答には、クライアントの要求と一致するサービスの場所が含まれています。属性やサービスタイプに関する要求や応答も可能です。詳細は、第 20 章「SLP (リファレンス)」を参照してください。
以下の図は、フレームワークに DA が配置された場合の、SLP アーキテクチャを実装する基本的なエージェントとプロセスを示しています。
DA を配置すると、ネットワークにはより少ないメッセージが送られるので、UA は情報をすばやく受け取ることができます。DA は、ネットワークのサイズが増大する場合やマルチキャストルーティングがサポートされていない場合に必要です。DA は登録されたサービス通知のキャッシュの役割を果たします。SA は DA に対して、通知するすべてのサービスをリストした登録メッセージ (SrvReg) を送り、その応答として確認応答 (SrvAck) を受け取ります。サービス通知は DA によって更新されるか、通知に設定された有効期限に従って期限切れになります。UA が DA を検出すると、UA は要求を SA にマルチキャストするのではなく、DA にユニキャストします。
Solaris SLP メッセージについての詳細は、第 20 章「SLP (リファレンス)」を参照してください。
Solaris SLP の実装では、SLP の SA、UA、DA、SA サーバー、スコープなどのアーキテクチャ部品 (表 16–1 を参照) の一部が slpd にマップされ、一部がアプリケーションプロセスにマップされます。SLP デーモン (slpd) は、特定のオフホストの SLP 相互作用を構成して、次のことを実行します。
ネットワーク上のすべての DA に対し、ディレクトリエージェントの受動的検出と能動的検出を使用する
ローカルホスト上の UA と SA が使用するために DA の更新テーブルを保持する
レガシーサービス通知に対してプロキシ SA サーバーとして機能する (プロキシ登録)
net.slpisDA プロパティを設定し、slpd が DA として機能するように構成することもできます。第 18 章「SLP の管理 (手順)」を参照してください。
SLP デーモンについては、slpd(1M)のマニュアルページを参照してください。
slpd の他に、C/C++ クライアントライブラリと Java クライアントライブラリ (libslp.so および slp.jar) が、UA クライアントと SA クライアントに SLP のフレームワークへのアクセスを提供します。クライアントライブラリは、次の機能を提供します。
サービス通知の登録と登録解除が可能なネットワークサービスを提供するソフトウェア
サービス通知にクエリーを発行することによってサービスを要求できるクライアントソフトウェア
登録と要求に使用できる SLP スコープのリスト
slpd とクライアントライブラリ (前述のサービスを提供する) 間のプロセス間通信を可能にするには、特別な構成は必要ありません。ただし、ライブラリが機能するように、先に slpd プロセスを実行してからクライアントライブラリをロードする必要があります。
次の図で、サービスプロバイダプログラム内の SLP クライアントライブラリは、SA の機能を使用します。サービスプロバイダプログラムは SLP クライアントライブラリを使用して、サービスを slpd に登録または登録解除します。サービスクライアントプログラムの SLP クライアントライブラリは、UA の機能を使用します。サービスクライアントプログラムは SLP クライアントライブラリを使用して、要求を出します。SLP クライアントライブラリは、SA に要求をマルチキャストするか、DA に要求をユニキャストします。この通信はアプリケーションから見て透過です。ただし、ユニキャスト方式の要求発行はより高速になります。クライアントライブラリの動作は、SLP のさまざまな構成プロパティの設定によって影響を受けます。第 18 章「SLP の管理 (手順)」を参照してください。slpd プロセスは、マルチキャスト要求への応答、DA への登録など、SA の全機能を処理します。
SLP の詳細は、次の文書を参照してください。
Kempf、James、Pete St. Pierre 著、『Service Location Protocol for Enterprise Networks』、John Wiley & Sons, Inc. (ISBN 番号 :0–47–3158–7)
『Authentication Management Infrastructure Administration Guide』(パート番号 :805–1139–03)
Guttman、Erik、Charles Perkins、John Veizades、Michael Day 著、『Service Location Protocol, Version 2, RFC 2608』、Internet Engineering Task Force (IETF) 。[ http://www.ietf.org/rfc/rfc2608.txt]
Kempf、James、Erik Guttman 著、『An API for Service Location, RFC 2614』、Internet Engineering Task Force (IETF) 。[http://www.ietf.org/rfc/rfc2614.txt]
この章では、SLP の計画と有効化について説明します。次の節では、SLP の構成と SLP を有効にするためのプロセスを取り上げています。
Solaris 9 では、オペレーティング環境といっしょにインストールされるように、SLP デーモンがデフォルトのプロパティで構成済みです。デフォルトの設定で正しく動作する場合、SLP の配置において、ほとんど管理は必要ありません。
ただし場合によっては、デフォルトの SLP プロパティを変更して、SLP のネットワーク動作を調整することや各種の SLP 機能を有効にすることが必要になります。たとえば、いくつかの構成を変更して、SLP のロギングを有効にすることができます。SLP のログ情報と snoop トレースの情報によって、追加の構成が必要かどうかを判断できます。
SLP 構成プロパティは、/etc/inet ディレクトリ内の slp.conf ファイルにあります。デフォルトのプロパティ設定を変更する場合は、第 18 章「SLP の管理 (手順)」の該当する手順を参照してください。
SLP 構成プロパティの設定を変更する前に、ネットワーク管理で大切な次のことがらを検討してください。
動作しているネットワーク技術の種類
ネットワーク技術が円滑に処理できるトラフィック量
ネットワークで使用できるサービスの数と種類
ネットワーク上のユーザー数、ユーザーが必要とするサービス、もっとも頻繁にアクセスするサービスに関係するユーザーの場所
SLP 対応の snoop ユーティリティと SLP ログユーティリティを使用して、再構成が必要かどうかや、変更する必要があるプロパティを判断できます。たとえば、次の目的のために特定のプロパティを再構成する場合があります。
各種の応答時間および帯域幅の性質が混在するネットワークメディアを調整する
ネットワークの障害または計画されていないパーティション分割から回復させる
DA を追加して SLP マルチキャストの急増を軽減する
新規のスコープを実装して、もっとも頻繁にアクセスするサービスにユーザーを編成する
snoop ユーティリティは受動的に機能する管理ツールで、ネットワークのトラフィック情報を提供します。ユーティリティ自身が発するトラフィックは最小限で、ネットワーク上のすべての動作を監視できます。
snoop ユーティリティは、実際の SLP メッセージトラフィックのトレースを行います。たとえば、snoop に slp コマンド行引数を付けて実行すると、登録および登録解除の SLP トレース情報が表示されます。このトレース情報を使用して、登録されているサービスの種類および登録動作の量をチェックできるので、ネットワークの負荷を測定できます。
snoop ユーティリティは、SLP ホスト間のトラフィックフローの監視にも役立ちます。snoop に slp コマンド行引数を付けて実行し、次の種類の SLP 動作を監視することで、ネットワークまたはエージェントの再構成が必要かどうかを判断できます。
特定の DA を使用しているホスト数。この情報により、負荷を均等にするために DA をさらに追加して配置するかどうかを判断できる
特定の DA を使用しているホスト数。この情報により、特定のホストに新規または別のスコープを構成すべきかどうかを判断できる
UA がタイムアウトを要求しているか、あるいは DA の確認応答が遅いかどうか。UA のタイムアウトや再伝送を監視することで、DA が過負荷になっているかどうかを判断できる。DA が SA に登録の確認応答を送るのに数秒以上かかっているかどうかも確認できる。この情報により、必要に応じて、DA を追加したりスコープの構成を変更したりして、DA にかかるネットワーク負荷を調整する
snoop に -V (詳細) コマンド行引数を付けて実行すると、登録の有効期限や SrvReg の新規フラグの値を得ることができるので、再登録の数を削減すべきかどうかを判断できます。
snoop を使用して、次のような別の種類の SLP トラフィックをトレースすることもできます。
UA クライアントと DA 間のトラフィック
UA クライアントのマルチキャストとそれに対する SA の応答との間のトラフィック
snoop については、snoop(1M) のマニュアルページを参照してください。
トラフィックおよび輻輳の統計情報を表示するには、netstat コマンドを snoop と併せて使用します。netstat の詳細は、netstat(1M) のマニュアルページを参照してください。
スーパーユーザーになります。
snoop に slp コマンド行引数を付けて実行します。
簡易モード : # snoop slp |
snoop をデフォルトの簡易モードで実行すると、進行中の出力が画面に表示されます。SLP メッセージは SLP トレースあたり 1 行に収まるように切り捨てられます。
詳細モード : # snoop -v slp |
snoop を 詳細モードで実行すると、進行中の出力がすべて画面に表示されます。出力される情報は次のとおりです。
サービス URL の完全なアドレス
すべてのサービス属性
登録の有効期限
すべてのセキュリティパラメータとフラグ (存在する場合)
slp コマンド行引数を snoop の他のオプションとともに使用できます。
次の例では、slpd は slphost1 上で SA サーバーとしてデフォルトモードで動作しています。SLP デーモンは、slphost2 をエコーサーバーとして初期化して登録しています。その後、snoop slp プロセスが slphost1 上で呼び出されます。
トレース結果を説明しやすくするために、次の snoop からの出力結果にトレース行番号を付けています。
1slphost1 -> 239.255.255.253 SLP V@ SrvRqst [24487] service:directory-agent [] 2slphost2 -> slphost1 SLP V2 DAAdvert [24487] service:directory-agent://129 3slphost1 -> 239.255.255.253 SLP V2 SrvRqst [24487] service:directory-agent [] 4slphost1 -> 239.255.255.253 SLP V2 SrvRqst [24487] service:directory-agent [] 5slphost1 -> slphost2 SLP V2 SrvReg [24488/tcp]service:echo.sun:tcp://slphost1: 6slphost2 -> slphost1 SLP V2 SrvAck [24488/tcp] ok 7slphost1 -> slphost2 SLP V2 SrvDereg [24489/tcp] service:echo.sun:tcp://slphost1: 8slphost2 -> slphost1 SLP V2 SrvAck [24489/tcp] ok |
slphost1 上の slpd が、ディレクトリエージェントを探すために SLP マルチキャストグループアドレスにマルチキャストして、ディレクトリエージェントを能動検出していることを示しています。能動検出に対するメッセージ番号 (24487) は、トレース表示では角括弧内に示されます。
トレース 1 からの能動検出要求 24487 に対し、ホスト slphost2 上で DA として動作している slpd が応答したことを示します。slphost2 からのサービス URL は 1 行に収まるように切り捨てられています。トレース 1 および 2 のメッセージ番号が一致していることからわかるように、DA はマルチキャストディレクトリエージェント検出メッセージに応答して、DA 通知を送っています。
追加の DA に対する slphost1 上の UA からのマルチキャストを示します。slphost2 はすでに要求に応答しているため、ふたたび応答することはなく、他のどの DA も応答しません。
前の行で示したマルチキャストを繰り返しています。
slphost1 上の slpd は、SA クライアントが作成した登録をホスト slphost2 上の DA に転送します。エコーサーバーに対するユニキャストサービス登録 (SrvReg) が、slphost1 によって slphost2 上の DA に行われています。
slphost2 が slphost1 の SrvReg に対してサービス確認応答 (SrvAck) で応答していることを表し、登録が完了したことを示しています。
SA クライアントを稼働しているエコーサーバーと slphost1 上の SLP デーモンとの間のトラフィックは、snoop トレースでは表示されません。表示されないのは、snoop 動作がネットワークのループバックを超えて実行されているからです。
slphost1 上のエコーサーバーが、エコーサービス通知の登録を解除します。slphost1 上の SLP デーモンは、登録解除を slphost2 上の DA に転送します。
slphost2 が slphost1 に対してサービス確認応答 (SrvAck) で応答していることを表し、登録解除が完了したことを示しています。
トレース行 5、6、7、8 のメッセージ番号に追加されている /tcp パラメータは、メッセージ交換が TCP で発生したことを示しています。
SLP トラフィックを監視後、snoop トレースから集められた情報を使用して、SLP デフォルトの再構成が必要かどうかを判断できます。SLP プロパティ値の設定については、第 18 章「SLP の管理 (手順)」を参照してください。SLP メッセージとサービス登録については、第 20 章「SLP (リファレンス)」を参照してください。
SLP を有効にするには、SLP デーモン slpd を実行します。SLP は、SLP デーモン slpd の実行で有効になります。slpd を起動するためにサポートされているインタフェースが /etc/init.d/slpd スクリプトで、SLP 構成ファイル /etc/inet/slp.conf が存在すればデーモンを起動します。Solaris オペレーティング環境には、/etc/inet/slp.conf.example というファイルがあります。ブート時に SLP を有効にするには、このファイル名を /etc/inet/slp.conf に変更します。
この章では、SLP のエージェントとプロセスを構成するための情報と作業手順について説明します。
SLP 構成プロパティは、ネットワークの相互作用、SLP エージェントの特性、状態、およびログを制御します。ほとんどの場合、これらのプロパティのデフォルトの構成は変更する必要がありません。ただし、ネットワークの媒体またはトポロジが変更される場合は、次の目的を達成するためには、この章の手順を使用します。
ネットワークの応答時間を補正する
ネットワークの輻輳を軽減する
エージェントの追加、または IP アドレスの再割り当てを行う
SLP ログを起動する
SLP 構成ファイル /etc/inet/slp.conf を編集すると、次の表に示す処理を行うことができます。
表 18–1 SLP 構成の操作
操作 |
説明 |
---|---|
slpd が DA サーバーと SA サーバーのどちらで機能するかを指定する。SA サーバーがデフォルト |
net.slpisDA プロパティに True を設定する |
マルチキャストメッセージのタイミングを設定する |
net.slp.DAHeartBeat プロパティを設定して、請求されていない DA 通知を DA がマルチキャストする回数を制御する |
DA ロギングを使用可能にしてネットワークトラフィックを監視する |
net.slp.traceDATraffic プロパティに True を設定する |
/etc/inet/slp.conf ファイルは、SLP デーモンを再起動するたびにすべての SLP 動作を定義して起動します。構成ファイルは次の要素から成ります。
構成プロパティ
コメント行と注釈
net.slp.isDA や net.slp.DAHeartBeat などのすべての基本的な SLP プロパティは、次の書式で名前が付けられています。
net.slp.<keyword> |
SLP の動作は、slp.conf ファイル内のプロパティの値またはプロパティの組み合わせによって定義されます。プロパティは、SLP 構成ファイル内でキーと値の対で構成されています。次の例に示すように、キーと値の対は、プロパティ名とその設定値で構成されています。
<property name>=<value> |
各プロパティのキーはプロパティ名です。値はプロパティに、数値 (間隔または時間)、真偽の状態、または文字列値のパラメータを設定します。プロパティの値は次のデータ型の 1 つで構成されます。
真偽設定 (ブール型)
整数
整数のリスト
文字列
文字列のリスト
slp.conf ファイルにコメントを追加して、その行の性質および機能を説明できます。コメント行はファイルに任意に書き込めるので、管理する上で役立ちます。
構成ファイル内の設定には、大文字と小文字の区別がありません。詳細は、Guttman, Erik, James Kempf, Charles Perkins 著、Internet Engineering Task Force (IETF) 発行の『Service Templates and service: scheme RFC 2609』を参照してください。 (http://www.ietf.org/rfc/rfc2609.txt )
SLP 構成ファイルのプロパティ設定を変更するには、次の手順を実行します。SLP が使用できるクライアントまたはサービスソフトウェアは、SLP API を使用して、SLP 構成も変更できます。API については、Internet Engineering Task Force (IETF) 発行の『An API for Service Location, RFC 2614』を参照してください。(http://www.ietf.org/rfc/rfc2614.txt )
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
必要に応じて、/etc/inet/slp.conf ファイルのプロパティ設定を編集します。
SLP プロパティの設定については、構成プロパティ を参照してください。slp.conf プロパティを変更する別の例については、後述の各節を参照してください。slp.conf(4) のマニュアルページを参照してください。
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
slpd を停止または起動するとき、SLP デーモンは構成ファイルから情報を取得します。
たとえば、slpd.conf ファイルの net.slp.isDA プロパティに True を設定して、slpd が DA サーバーとして動作するように SA サーバーのデフォルトを変更できます。
net.slp.isDA=True |
各領域で、各種のプロパティが構成の異なる場合を制御します。以降の各節では、SLP 構成で使用するデフォルトのプロパティ設定を変更するさまざまなシナリオについて説明します。
次のような場合は、DA 通知と検出要求のタイミングを制御するプロパティを変更できます。
SA または UA が slp.conf ファイルの net.slp.DAAddresses プロパティから静的に DA 構成情報を取得するように設定したい場合は、DA 検出を無効にできる
ネットワークが頻繁にパーティション分割を行う場合は、受動的な通知および定期的な能動的検出の頻度を変更できる
UA と SA クライアントがダイアルアップ接続の一方の側で DA にアクセスしている場合は、DA のハートビート頻度と能動的検出の間隔を減らすことで、ダイアルアップ回線の起動回数を少なくできる
ネットワークが輻輳している場合は、マルチキャストを制限できる
この節の手順では、次のプロパティを変更する方法について説明します。
表 18–2 DA 通知タイミングと検出要求のプロパティ
プロパティ |
説明 |
---|---|
net.slp.passiveDADetection | |
net.slp.DAActiveDiscoveryInterval | |
net.slp.DAHeartBeat |
UA と SA が slp.conf ファイル内の静的な構成情報から DA アドレスだけを取得するように制限することが必要な場合があります。次の手順では、slpd が net.slp.DAAddresses プロパティから DA 情報だけを取得するように 2 つのプロパティを変更できます。
次の手順に従って、net.slp.passiveDADetection および net.slp.DAActiveDiscoveryInterval プロパティを変更します。
この手順は、静的な構成を使用するように制限されている UA と SA を実行するホストにだけ使用してください。
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
slp.conf ファイル内の net.slp.passiveDADetection プロパティに False を設定して、受動的検出を無効にします。この設定により、slpd は請求されていない DA 通知を無視します。
net.slp.passiveDADetection=False |
net.slp.DAActiveDiscoveryInterval に -1 を設定して、初期および定期の能動的検出を無効にします。
net.slp.DAActiveDiscoveryInterval=-1 |
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
UA または SA がダイアルアップネットワークによって DA から切り離されている場合は、DA 検出を構成して、検出要求と DA 通知の数を削減するか、完全になくすことができます。ダイアルアップネットワークでは、通常起動時に課金されます。余分な通話を最小限に抑えることにより、ダイアルアップネットワークの使用コストを削減できます。
UA と SA を静的に構成された DA に限定する で説明している方法で、DA 検出を完全に無効にすることができます。
次の手順に従って、DA ハートビートの期間と能動的検出の間隔を長くすることで、請求されていない DA 通知と能動的検出を削減できます。
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
slpd.conf ファイル内の net.slp.DAHeartbeat プロパティの値を大きくします。
net.slp.DAHeartbeat=value |
32 ビットの整数で、DA 通知の受動的ハートビートに対して秒数を設定する
デフォルト値は、10800 秒 (3 時間)
値の範囲は、2000 から 259200000 秒
たとえば、DA を実行しているホストに対して、DA のハートビートを約 18 時間に設定できます。
net.slp.DAHeartbeat=65535 |
slpd.conf ファイル内の net.slp.DAActiveDiscoveryInterval プロパティの値を大きくします。
net.slp.DAActiveDiscoveryInterval value |
32 ビットの整数で、DA の能動的検出クエリーに対して秒数を設定する
デフォルトの値は、900 秒 (15 分)
値の範囲は、300 から 10800 秒
たとえば、UA と SA を実行しているホストに対して、DA の能動的検出の間隔を 18 時間に設定できます。
net.slp.DAActiveDiscoveryInterval=65535 |
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
スコープをサポートするすべての DA に登録するには、SA が必要です。DA は、slpd が能動的検出を行なった後で現れることがあります。DA が slpd スコープをサポートする場合、SLP デーモンはホスト上のすべての通知を DA に登録します。
slpd が DA を検出する 1 つの方法は、起動時に DA が送り出す初期の請求されていない通知を使用します。SLP デーモンは定期的な請求されていない通知 (ハートビート) を使用して、DA がまだアクティブであるかどうかを判断します。ハートビートが出現しない場合、SLP デーモンは自分が使用する DA を削除し、これを UA に申し出ます。
最後に、DA にシャットダウン要求が出されると、DA は特別な DA 通知を転送して、受信中の SA サービスに DA がサービスから抜け出すことを知らせます。SLP デーモンもこの特別な通知を使用して、キャッシュからアクティブでない DA を削除します。
ネットワークが頻繁にパーティション分割を行い、SA の期限が長い場合、ハートビートの通知を受けなければ、slpd はパーティションの分割中に DA をキャッシュから削除できます。ハートビートの頻度を減らすことにより、使用中止になった DA がパーティションの修正後にキャッシュに復元されるまでの遅延時間を縮小できます。
次の手順に従って、net.slp.DAHeartBeat プロパティを変更し、DA のハートビート期間を短くします。
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
DA のハートビートの値を 1 時間 (3600 秒) に縮小します。デフォルトでは、DA のハートビート期間は 3 時間 (10800 秒) に設定されています。
net.slp.DAHeartBeat=3600 |
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
DA 検出が完全に無効になっている場合、ホスト上で実行されている UA と SA が正しい DA にアクセスするように、net.slp.DAAddresses プロパティを slp.conf に設定する必要があります。
ネットワークが非常に混雑している場合、マルチキャストの量を制限できます。ネットワークに DA を配置していない場合は、DA を配置すると SLP 関連のマルチキャストの量を大幅に削減できます。
ただし、DA の配置後でも DA 検出のためのマルチキャストは必要です。 DA 検出に必要なマルチキャストの量は、ダイアルアップネットワークに対する DA 検出の構成方法 で説明している方法で削減できます。UA と SA を静的に構成された DA に限定する で説明している方法で、DA 検出のためのマルチキャストを完全になくすことができます。
この節では、次のプロパティを変更して SLP のパフォーマンスを調整する場合の可能なシナリオについて説明します。
表 18–3 SLP パフォーマンスのプロパティ
プロパティ |
説明 |
---|---|
net.slp.DAAttributes |
DA が通知を受け取る最短の更新間隔 |
net.slp.multicastTTL |
マルチキャストパケットの有効期限 |
net.slp.MTU |
ネットワークパケットのサイズ (バイト)。サイズには、IP と TCP または UDP の各ヘッダーが含まれている |
net.slp.isBroadcastOnly |
ブロードキャストを DA サービス検索および DA ベースでないサービス検索に使用する必要があるかどうかを示すために設定されるブール値 |
SA は、期限が切れる前に定期的にサービス通知を更新する必要があります。DA が多くの UA と SA の非常に重い負荷を処理している場合は、頻繁な更新により DA が過負荷になることがあります。DA が過負荷になると、UA の要求がタイムアウトして欠落します。UA 要求のタイムアウトには多くの原因が考えられます。DA の過負荷が問題であると仮定する前に、snoop トレースを使ってサービス登録に登録されているサービス通知の有効期限を確認してください。有効期限が短く、再登録が頻繁に発生している場合は、再登録が頻繁すぎることがタイムアウトの原因と考えられます。
サービス登録は、FRESH フラグが設定されていなければ再登録になります。サービス登録メッセージについては、第 20 章「SLP (リファレンス)」を参照してください。
次の手順に従って、SA の最小更新間隔を長くすることで、再登録回数を削減します。
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
net.slp.DAAttributes プロパティの min-refresh-interval 属性の値を大きくします。
デフォルトの最短再登録期間はゼロ (0) です。デフォルトがゼロの場合、SA はいつでも自由に再登録できます。次の例では、間隔は 3600 秒 (1 時間) に増やしています。
net.slp.DAAttributes(min-refresh-interval=3600) |
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
マルチキャストの有効期限プロパティ (net.slp.multicastTTL) によって、マルチキャストパケットがイントラネット内で伝達される範囲が決まります。マルチキャスト TTL は net.slp.multicastTTL プロパティを 1 から 255 までの整数に設定することにより構成されます。マルチキャスト TTL のデフォルト値は 255 で、これは理論的にはパケット経路が無制限であることを意味します。しかし、TTL を 255 とすると、マルチキャストパケットがイントラネットを超えて管理ドメインの端にある境界ルーターまで進む原因になります。マルチキャストパケットがインターネットのマルチキャストバックボーンまたは ISP に漏れないようにするには、境界ルーター上のマルチキャストが正しく構成されている必要があります。
マルチキャスト TTL のスコープ設定は、TTL 比較が作成されることを除いて、標準的な IP の TTL と似ています。マルチキャストを実行できるルーター上の各インタフェースには、TTL 値が割り当てられています。マルチキャストパケットが着信すると、ルーターはパケットの TTL をインタフェースの TTL と比較します。パケットの TTL がインタフェースの TTL 値と同じかそれより大きい場合は、標準的な IP の TTL の場合と同じように、パケットの TTL を 1 減らします。TTL がゼロになると、そのパケットは破棄されます。SLP マルチキャストに TTL スコープを使用する場合、パケットをイントラネットの特定のサブセクションに限定するために、ルーターが正しく構成されている必要があります。
次の手順に従って、net.slp.multicastTTL プロパティを設定し直します。
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
slpd.conf ファイル内の net.slp.multicastTTL プロパティを変更します。
net.slp.multicastTTL=value |
マルチキャスト TTL を定義する 255 以下の正の整数
TTL 値を減らしてマルチキャストの伝達範囲を縮小することができます。TTL の値が 1 の場合、パケットはそのサブネットに限定されます。TTL の値が 32 の場合は、パケットはそのサイトに限定されます。「サイト」は、マルチキャスト TTL について記述されている RFC 1075 では定義されていません。32 以上の値は、インターネット上の論理的な経路を指すので使用しないでください。32 未満の値は、各ルーターが TTL で正しく構成されていれば、マルチキャストをアクセス可能なサブネットのセットに限定するために使用できます。
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
SLP のデフォルトのパケットサイズは 1400 バイトです。ほとんどのローカルエリアネットワークにはこのサイズで十分です。無線ネットワークまたは広域ネットワークの場合は、メッセージの断片化を防いだりネットワークのトラフィックを削減したりするために、パケットサイズを縮小できます。より大きなパケットを持つローカルエリアネットワークの場合は、パケットサイズを大きくするとパフォーマンスが向上します。ネットワークの最小パケットサイズを確認して、パケットサイズの縮小が必要かどうかを判断できます。ネットワーク媒体のパケットサイズがより小さい場合は、パケットサイズに合わせて net.slp.MTU の値を小さくできます。
ネットワーク媒体のパケットサイズがより大きい場合は、パケットサイズに合わせて値を大きくできます。ただし、SA からのサービス通知または UA からのクエリーが頻繁にデフォルトのパケットサイズをオーバーフローするのでなければ、net.slp.MTU の値を変更する必要はありません。snoop を使用して、UA 要求がデフォルトのパケットサイズを頻繁にオーバーフローし、UDP ではなく TCP を使用するためにロールオーバーしているかどうかを判断できます。
net.slp.MTU プロパティは、リンク層ヘッダー、IP ヘッダー、UDP または TCP ヘッダー、SLP メッセージを含めた、IP パケットの全体サイズを測定します。
次の手順に従って、net.slp.MTU プロパティを調整することで、デフォルトのパケットサイズを変更します。
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
slpd.conf ファイル内の net.slp.MTU プロパティを変更します。
net.slp.MTU=value |
16 ビットの整数で、ネットワークのパケットサイズ (バイト単位)
デフォルト値は、1400
値の範囲は、128 から 8192
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
SLP は、DA が存在しない場合に、マルチキャストを使ってサービス検出や DA 検出を行うように設計されています。使用するネットワークが、マルチキャストルーティングを配置しない場合は、net.slp.isBroadcastOnly プロパティに True を設定することで、SLP がブロードキャストを使用するように構成できます。
マルチキャストと異なり、ブロードキャストパケットはデフォルトの場合サブネットを越えて伝達しません。このため、マルチキャストを行わないネットワークでは、DA を使用しないサービス検出は、単一のサブネット上でしか機能しません。さらに、ブロードキャストが使用されているネットワークに DA およびスコープを配置する場合は、特別な考慮が求められます。マルチホームホスト上の DA は、マルチキャストが使用できない複数のサブネット間でサービス検出をブリッジできます。マルチホームホスト上の DA の配置については、DA の配置とスコープ名の割り当て を参照してください。
次の手順に従って、net.slp.isBroadcastOnly プロパティを True に変更します。
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
slpd.conf ファイル内の net.slp.isBroadcastOnly プロパティを True に変更します。
net.slp.isBroadcastOnly=True |
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
SLP 検出要求のタイムアウトを変更する必要があるのは、次の 2 つの場合です。
SLP エージェントが複数のサブネット、ダイアルアップ回線、または別の WAN によって切り離されている場合は、ネットワークの応答時間が長く、デフォルトのタイムアウトでは要求や登録を完了できないことがある。逆に、ネットワークの応答時間が短い場合は、タイムアウトを短くすることにより、パフォーマンスが向上することがある
トラフィックが多いネットワークまたは衝突率の高いネットワークの場合、SA および UA がメッセージを送る前に待たなければならない最長の時間が不足して、衝突のないトランザクションを確保できない場合がある
ネットワークの応答時間が長いと、UA および SA が要求と登録を行う場合、応答を受け取る前にタイムアウトになる原因になります。複数のサブネット、ダイアルアップ回線、または WAN によって UA が SA から切り離されている場合、または UA と SA の両方が DA から切り離されている場合、応答時間が問題となることがあります。応答時間が問題であるかどうかを判断するには、UA および SA の要求と登録でタイムアウトが起こったために SLP 要求が失敗しているかどうかを確認します。ping コマンドを使って実際の応答時間を測定することもできます。
次の表は、タイムアウトを制御する構成プロパティを示します。この節で説明する手順で、これらのプロパティを変更できます。
表 18–4 タイムアウトプロパティ
プロパティ |
説明 |
---|---|
net.slp.multicastTimeouts net.slp.DADiscoveryTimeouts net.slp.datagramTimeouts |
これらのプロパティは、メッセージ転送が中止されるまで、マルチキャストやユニキャストが繰り返し実行する UDP メッセージの転送に使用できるタイムアウトのリストを制御する |
net.slp.multicastMaximumWait |
このプロパティは、マルチキャストメッセージが中止されるまで、転送される最長時間を制御する |
net.slp.datagramTimeouts |
このプロパティにリストされる値の合計を示す DA タイムアウトの上限。UDP ダイアグラムは、応答を受け取るかタイムアウトの上限になるまで、DA に繰り返し送られる |
マルチキャストサービスの検出中または DA の検出中に頻繁にタイムアウトが発生する場合は、net.slp.multicastMaximumWait プロパティをデフォルト値の 15000 ミリ秒 (15 秒) から増やしてください。最大待ち時間を長くすることにより、応答時間の長いネットワーク上で要求に対してより長い時間が許可されます。net.slp.multicastMaximumWait プロパティの値を増やした後は、net.slp.multicastTimeouts と net.slp.DADiscoveryTimeouts も変更する必要があります。これらのプロパティのタイムアウト値の合計が net.slp.multicastMaximumWait 値と等しくなるようにしてください。
次の手順に従って、タイムアウトを制御する SLP プロパティを変更します。
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
slpd.conf ファイル内の net.slp.multicastMaximumWait プロパティを変更します。
net.slp.multicastMaximumWait=value |
32 ビットの整数で、net.slp.multicastTimeouts と net.slp.DADiscoveryTimeouts に設定する値の合計値を示す
デフォルト値は、15000 ミリ秒 (15 秒)
値の範囲は、1000 から 60000 ミリ秒
たとえば、マルチキャスト要求で 20 秒 (20000 ミリ秒) 必要だと判断したら、net.slp.multicastTimeouts プロパティと net.slp.DADiscoveryTimeouts プロパティにリストされている値の合計が 20000 ミリ秒になるように調整します。
net.slp.multicastMaximumWait=20000 net.slp.multicastTimeouts=2000,5000,6000,7000 net.slp.DADiscoveryTimeouts=3000,3000,6000,8000 |
slpd.conf ファイル内の net.slp.datagramTimeouts プロパティを必要に応じて変更します。
net.slp.datagramTimeouts=value |
32 ビット整数のリストで、ユニキャストのデータグラム転送を DA に実行するためのタイムアウト (ミリ秒)
デフォルト値は、3000,3000,3000
たとえば、頻繁なタイムアウトの発生を回避するために、データグラムのタイムアウトを 20000 ミリ秒に増やすことができます。
net.slp.datagramTimeouts=2000,5000,6000,7000 |
高パフォーマンスのネットワークでは、逆に UDP データグラム転送のマルチキャストまたはユニキャストのタイムアウトの上限を小さくできます。 タイムアウトの上限を小さくすることで、SLP 要求を満たすために必要な応答時間を短縮できます。
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
トラフィックの重いネットワークや衝突率の高いネットワークでは、DA との通信が影響を受けることがあります。衝突率が高い場合、送信エージェントは、UDP データグラムを再転送する必要があります。再転送が発生しているかどうかは、snoop を使用して、SA サーバー として slpd を実行しているホスト、および DA として slpd を実行しているホストのネットワークトラフィックを監視することにより判断できます。 SA サーバーとして slpd を実行しているホストから同じサービスについて複数のサービス登録メッセージが snoop トレースに現れる場合は、衝突の問題があると考えられます。
衝突は、ブート時の主要な問題となる場合があります。DA が最初に起動されると、DA は請求されていない通知を送り出し、SA はそれらの登録に応答します。SLP は、DA 通知を受け取ってから応答するまでにランダムな時間だけ、SA を待たせます。このランダムな待ち時間は、net.slp.randomWaitBound によって制御される最大値を使って均等に分散されます。デフォルトのランダム待ち時間の上限は 1000 ミリ秒 (1 秒) です。
次の手順に従って、slp.conf ファイルの net.slp.RandomWaitBound プロパティを変更します。
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
slpd.conf ファイル内の net.slp.RandomWaitBound プロパティを変更します。
net.slp.RandomWaitBound=value |
DA に接続するまでのランダム待ち時間の計算に使用される上限
デフォルト値は、1000 ミリ秒 (1 秒)
値の範囲は、1000 から 3000 ミリ秒
たとえば、ランダム待ち時間を 5000 ミリ秒 (5 秒) に延長できます。
net.slp.randomWaitBound=5000 |
ランダム待ち時間の上限を長くすると、登録で遅延が長くなります。SA は新しく検出された DA をより時間をかけて登録できるので、衝突とタイムアウトを回避することができます。
slpd.conf ファイル内の net.slp.datagramTimeouts プロパティを必要に応じて変更します。
net.slp.datgramTimeouts=value |
32 ビット整数のリストで、ユニキャストのデータグラム転送を DA に実行するためのタイムアウト (ミリ秒)
デフォルト値は、3000,3000,3000
たとえば、頻繁なタイムアウトの発生を回避するために、データグラムのタイムアウトを 20000 ミリ秒に増やすことができます。
net.slp.datagramTimeouts=2000,5000,6000,7000 |
高パフォーマンスのネットワークでは、逆に UDP データグラム転送のマルチキャストまたはユニキャストのタイムアウトの上限を小さくできます。 この設定により、SLP 要求を満たす際に、応答時間を短縮できます。
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
スコープを使用すると、論理的、物理的、および管理上のユーザーのグループによるサービスへの対応が可能です。スコープを使用することで、サービス通知へのアクセスの管理が可能になります。
net.slp.useScopes プロパティを使用すると、スコープを作成できます。たとえば、次のように構成すると、ホスト上の /etc/inet/slp.conf ファイルに、newscope という名前の新規のスコープが追加されます。
net.slp.useScopes=newscope |
スコープの概念を理解しやすくするために、会社にプリンタや FAX などのネットワーク接続されたオフィス機器の小部屋がビルディング 6 の 2 階の南の大部屋の端にあるとします。これらのオフィス機器は 2 階のすべてのユーザーに提供されている場合や、使用が特定の部署のメンバーに限定されている場合があります。スコープはこれらの機器に対するサービス通知へのアクセスに対応する手段を提供します。
オフィス機器をマーケティング部専用にすると、mktg という名前のスコープを作成することができます。別の部署に所属しているオフィス機器は、別のスコープ名で構成できます。
また、部署が分散している場合もあります。たとえば、機械工学部門と CAD/CAM 部門が 1 階と 2 階に分かれているとします。この場合でも、両者に同じスコープを割り当てることにより、1 階と 2 階にあるホストに 2 階のマシンを提供できます。ネットワークとユーザーに都合よく動作するように、スコープはどのように配置してもかまいません。
特定のスコープを持つ UA は、別のスコープで通知されたサービスを実際に使用できないわけではありません。スコープの構成は、UA が検出するサービス通知を制御するだけです。サービス自体が、なんらかのアクセス制御の制限を行う必要があります。
SLP はスコープ構成をまったく行わなくても十分機能します。Solaris オペレーティング環境では、SLP のデフォルトのスコープは default です。構成されているスコープがない場合は、default がすべての SLP メッセージのスコープになります。
次の環境のどれかに当てはまれば、スコープを構成できます。
サポートしている組織が、所属メンバーに対するサービス通知アクセスを制限する場合
サポートしている組織が、特定のユーザーが特定領域のサービスにアクセスするように物理的に配置されている場合
ユーザーが認識できるサービス通知を分割する必要がある場合
最初の場合の例を ダイアルアップネットワークに対する DA 検出の構成 に挙げました。2 番目の例は、組織が 2 つの建物に分かれていて、1 つの建物のユーザーはその建物のローカルサービスにアクセスするようにしたい場合です。ビルディング 1 のユーザーはスコープ B1 を使用して、ビルディング 2 のユーザーはスコープ B2 を使って構成できます。
slpd.conf ファイル内の net.slp.useScopes プロパティを変更する場合は、ホスト上のすべてのエージェントにスコープを構成します。ホストが SA を実行している場合や DA として機能している場合に、その SA と DA に default 以外のスコープを構成するには、このプロパティを構成する必要があります。UA だけがマシン上で動作し、UA が、default 以外のスコープをサポートしている SA と DA を検出する必要がある場合は、UA が使用するスコープを制限するのでなければ、プロパティを構成する必要はありません。プロパティを構成しない場合、UA は、slpd を通じて、使用可能な DA とスコープを自動的に検出します。SLP デーモンは、能動的および受動的 DA 検出を使用して DA を見つけるか、DA が動作していない場合は SA 検出を使用して DA を見つけます。プロパティを構成する場合、UA は構成されたスコープを使用するだけで、構成されたスコープを破棄することはありません。
スコープを構成することを決定した場合、ネットワークのすべての SA にスコープが構成されていることを確認できなければ、構成されたスコープのリストに default スコープを保存することを考えてください。構成されていない SA があると、構成されたスコープを持つ UA はそれらの SA を見つけることができません。これは、構成されていない SA が自動的に default スコープを持つのに対し、UA は構成されたスコープを持つためです。
net.slp.DAAddresses プロパティを設定して DA も構成しようとする場合は、構成される DA によってサポートされるスコープが、net.slp.useScopes プロパティで構成したスコープと同じであることを確認してください。スコープが同じでない場合は、再起動時に slpd がエラーメッセージを出力します。
次の手順に従って、スコープ名を slp.conf ファイルの net.slp.useScopes プロパティに追加します。
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
slpd.conf ファイル内の net.slp.useScopes プロパティを変更します。
net.slp.useScopes=<scope names> |
文字列のリストで、DA または SA が要求時に使用を許されるスコープを示すか、DA がサポートする必要があるスコープを示す
デフォルトの値は、SA と DA の場合は Default、UA の場合は未設定
大文字または小文字の英数字
句読点 (''、 \、!、<、 =、>、および ~ を除く)
名前の一部と考えられるスペース
非 ASCII 文字
ASCII でない文字をエスケープするには、バックスラッシュを使用します。たとえば、UTF-8 コード体系では、フランス語の aigue アクセントのある文字 e を表すために、16 進コード 0xc3a9 を使用します。プラットフォームが UTF-8 をサポートしていない場合は、UTF-8 の 16 進コード \c3\a9 をエスケープシーケンスとして使用します。
ここでは、例として、bldg6 にスコープ eng と mktg を作成することを考えます。この場合は、net.slp.useScopes 行を次のように変更します。
net.slp.useScopes=eng,mktg,bldg6 |
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
この節では、SLP を実行しているネットワークでの計画的な DA の配置について説明します。
配置された DA または構成されたスコープがなくても、基本のエージェントである UA と SA だけで SLP は十分機能します。特定の構成を持たないすべてのエージェントは自動的に default スコープを使用します。DA はサービス通知のキャッシュとして機能します。DA を配置すると、ネットワークに送られるメッセージ数が削減されるため、メッセージ応答の受け取りに必要な時間も短縮されます。これにより、SLP をより大規模なネットワークに対応させることができます。
DA を配置する主な目的は、サービス検出によって生じるマルチキャストトラフィックの量とユニキャスト応答の収集に関係する遅延を削減することです。多くの UA と SA を持つ大規模なネットワークでは、サービス検出によって生じるマルチキャストの量が非常に大きくなるので、ネットワークのパフォーマンスが低下します。1 つまたは複数の DA を配置すると、UA はサービスについて DA にユニキャストし、SA はユニキャストを使用して DA に登録する必要があります。DA を使用したネットワークでは、SLP 登録されたマルチキャストは、能動的および受動的 DA 検出のマルチキャストだけです。
SA は、マルチキャストのサービス要求を受け取るのではなく、共通のスコープのセット内で検出した任意の DA に自動的に登録します。ただし、DA がサポートしていないスコープ内のマルチキャスト要求には、SA が直接応答します。
UA から出されたサービス要求は、UA のスコープ内に DA が配置されている場合は、ネットワーク上へのマルチキャストではなく DA に対するユニキャストです。そのため、UA のスコープ内に DA を配置すると、マルチキャストが削減されます。通常の UA 要求を行うマルチキャストをなくすことにより、クエリー応答の受け取りに必要な時間が秒単位からミリ秒単位に大幅に縮小します。
DA は SA および UA の動作の中心として機能します。スコープの集合に対して 1 つまたは複数の DA を配置することにより、SLP の動作を監視するための集中的なポイントが提供されます。DA ログを起動することにより、ネットワークに散在している複数の SA から取り寄せたログをチェックするよりも、登録および要求の監視が容易になります。負荷を均等にする必要に合わせて、1 つまたは複数の特定のスコープに対して DA をいくつでも配置できます。
マルチキャストルーティングが使用できないネットワークでは、SLP がブロードキャストを使用するように構成できます。しかし、ブロードキャストは各ホストにメッセージを処理するように要求するため、非常に効率が悪くなります。また、ブロードキャストは通常、ルーターを超えて伝達されません。この結果、マルチキャストルーティングに対応していないネットワークでは、同じサブネットでしかサービスを検出できません。マルチキャストルーティングに一部しか対応していない場合は、ネットワーク上でサービスを検出する機能に矛盾が生じます。マルチキャストメッセージは DA の検出に使用されます。したがって、マルチキャストルーティングに一部しか対応していない場合は、UA と SA はサービスを SA のスコープ内にある既知の DA に登録することが暗黙の了解になっています。たとえば、UA が DA1 と呼ばれる DA にクエリーを出し、SA がサービスを DA2 に登録している場合、UA はサービスの検出に失敗します。マルチキャストが使用できないネットワーク上の SLP の配置については、ブロードキャスト専用ルーティングの構成 を参照してください。
サイト全体がマルチキャストルーティングに対応していないネットワークでは、net.slp.DAAdresseses プロパティを使用して、SLP の UA と SA が DA 位置に関して矛盾のないリストを持つように構成する必要があります。
最後に、Solaris SLPv2 の DA は SLPv1 との相互運用性をサポートしています。SLPv1 の相互運用は Solaris DA ではデフォルトで有効になっています。ネットワークにプリンタなどの SLPv1 デバイスが接続されている場合、またはサービス検出で SLPv1 を使用している Novell Netware 5 と相互運用する必要がある場合、DA を配置する必要があります。DA が配置されていないと、Solaris SLP の UA は SLPv1 によって通知されたサービスを見つけることができません。
次の条件のどれかに当てはまる場合は、エンタープライズに DA を配置します。
snoop で測定した、ネットワーク上での SLP のマルチキャストのトラフィックが帯域幅の 1% を超える
UA クライアントがサービス要求のマルチキャスト中に長時間遅延またはタイムアウトする
1 台または複数台のホスト上にある特定のスコープに対して、SLP サービス通知の監視を集中する
ネットワークが、サービスを共有する複数のサブネットから構成され、マルチキャストに対応していない
ネットワークが前バージョンの SLP (SLPv1) をサポートするデバイスを使用している、または SLP サービス検出で Novell Netware 5 と相互運用したい
次の手順に従って、slp.conf ファイルの net.slp.isDA プロパティに True を設定します。
1 台のホストにつき 1 つの DA だけが割り当てられます。
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
slpd.conf ファイル内の net.slp.isDA プロパティに True を設定します。
net.slp.isDA=True |
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
この節は、DA を配置する場所について状況ごとにヒントを示します。
マルチキャストルーティングが使用できず、DA がサブネット間のサービス検出をブリッジする必要がある場合
この場合は、インタフェースとサービスを共有するすべてのサブネットを持つホスト上に DA を配置してください。IP パケットがインタフェースの間を経路指定されない場合を除き、net.slp.interfaces 構成プロパティを設定する必要はありません。net.slp.interfaces プロパティの設定については、マルチホームの構成 を参照してください。
DA が拡張に備えて配置されており、考慮すべき主要な事柄がエージェントのアクセスの最適化である場合
UA は通常、DA に対してサービスを大量に要求します。SA がサービスを DA に登録すると、SA は通知を定期的に適切な頻度で更新できます。その結果、UA から DA へのアクセスの方が SA のアクセスよりはるかに頻繁になります。通常、サービス通知の数も要求の数より小さくなります。このため、UA のアクセスに対して DA の配置が最適化されている場合、多くの DA を配置することは効率化をうながします。
UA のアクセスを最適化するために、ネットワーク上でトポロジ的に UA の近くになるように DA を配置する場合
UA クライアントと SA クライアントの両方が共有しているスコープを使用して、DA を構成してください。
負荷を均等にする手段として、同じスコープの集合体について複数の DA を配置できます。次の状況のどれかに当てはまれば、DA を配置できます。
DA ログが、多くの SLP 要求が欠落していることを示す
スコープ内でサービスを共有しているユーザーのネットワークが、複数の建物や物理的なサイトに渡っている
SLP トラフィックの snoop トレースを行うことによって、どれくらいの UA 要求で DA_BUSY_NOW エラーが返されるかを判断することができます。返される UA 要求の数が多い場合は、DA から物理的およびトポロジ的に離れている建物内の UA は、応答が遅かったり過度にタイムアウトしたりすることがあります。このような場合、建物内の UA クライアントの応答を改善するために、建物ごとに DA を配置できます。
建物に接続しているリンクは、建物内のローカルエリアネットワークよりも遅いことがあります。ネットワークが複数の建物または物理的なサイトに渡っている場合は、/etc/inet/slp.conf ファイル内の net.slp.DAAddresses プロパティを特定のホスト名またはアドレスのリストに設定して、指定した DA だけに UA がアクセスするようにします。
特定の DA がサービス登録に対して大量のホストメモリーを消費している場合は、DA がサポートするスコープ数を減らすことによって、SA 登録の数を削減します。登録数の多いスコープを、たとえば 2 つのスコープに分けることができます。次に、片方の DA を別のホストに配置することによって、もう片方のスコープだけをサポートするようにできます。
マルチホームサーバーは、複数の IP サブネット上でホストとして機能します。そのようなサーバーに複数のネットワークインタフェースカードが装着されると、ルーターとして機能できます。マルチキャストパケットを含む IP パケットは、このインタフェース間を経路指定されます。場合によっては、インタフェース間の経路指定ができないことがあります。この節では、そのような場合に SLP を構成する方法について説明します。
構成を行わない場合、slpd はデフォルトのネットワークインタフェース上でマルチキャストと UDP/TCP ユニキャストに対して待機しています。 ユニキャストルーティングとマルチキャストルーティングがマルチホームマシンのインタフェース間で使用できる場合は、追加の構成を行う必要はありません。追加の構成が必要ないのは、別のインタフェースに到達するマルチキャストパケットがデフォルトで正確に経路指定されているからです。その結果、DA または他のサービス通知のマルチキャスト要求は、slpd に届きます。経路指定がなんらかの理由で調整されていない場合は、構成が必要です。
マルチホームマシンの構成が必要と考えられるのは、主に次の場合です。
ユニキャストルーティングはインタフェース間で使用できるが、マルチキャストルーティングは使用できない
ユニキャストルーティングとマルチキャストルーティングの両方がインタフェース間で使用できない
マルチキャストルーティングがインタフェース間で使用できない場合は、通常、マルチキャストがネットワークに配置されていないことが原因です。この場合は通常、それぞれのサブネット上の DA ベースでないサービス検出および DA 検出にブロードキャストが使用されます。ブロードキャストは、net.slp.isBroadcastOnly プロパティを True に設定することによって構成します。
作業 |
説明 |
参照先 |
---|---|---|
net.slp.interfaces プロパティを構成する |
このプロパティを設定することで、slpd は、指定されたインタフェース上でユニキャストとマルチキャスト/ブロードキャストの SLP 要求を待機できる | net.slp.interfaces プロパティの構成 |
サブネット上の UA が到達可能なアドレスを持つサービス URL を取得できるように、プロキシサービス通知を配置する |
マルチホームホストではなく単一のサブネットに接続された slpd を実行しているマシンにプロキシ通知を限定する | マルチホームホスト上のプロキシ通知 |
UA と SA 間で確実に到達できるように DA を配置してスコープを構成する |
マルチホーム上の net.slp.interfaces プロパティを単一インタフェースのホスト名またはアドレスで構成する。 マルチホームホスト上で DA を実行し、各サブネット上の SA と UA は別のホストを使用するように構成する | DA の配置とスコープ名の割り当て |
net.slp.interfaces プロパティが設定されている場合、slpd は、ユニキャストとマルチキャスト/ブロードキャストの SLP 要求を、デフォルトのインタフェース上ではなく、プロパティにリストされたインタフェース上で待機します。
通常、net.slp.interfaces プロパティを設定すると同時に、net.slp.isBroadcastOnly プロパティも設定することでブロードキャストを有効にします。ただし、マルチキャストは配置されているが、この特定のマルチホームホスト上で経路指定されていない場合、マルチキャスト要求は、複数のインタフェースから slpd に到達できます。このような状況は、パケットの経路指定が、別のマルチホームホストまたはインタフェースからサービスを受けるサブネットに接続されているルーターによって制御されている場合に起こります。
この場合、SA サーバーまたは要求を送っている UA は、マルチホームの slpd から 2 つの応答を受け取ります。これらの応答はクライアントライブラリによってフィルタにかけられて除かれるので、クライアントには見えません。ただし、この応答は、snoop トレースで見ることができます。
ユニキャストルーティングがオフになっている場合、マルチホームホスト上の SA クライアントによるサービス通知がすべてのサブネットに到達できないことがあります。サービスが到達できない場合、SA クライアントは次のことを実行できます。
個々のサブネットにつき 1 つのサービス URL を通知する
特定のサブネットからの要求が到達可能な URL で確実に応答されるようにする
SA クライアントライブラリには、到達可能な URL が確実に通知されるようにするためのしくみはありません。したがって、到達可能な URL が確実に通知されるようにするには、経路指定のないマルチホームホストを処理できるかどうかにかかわらず、サービスプログラムに任せる必要があります。
ユニキャストルーティングが無効なマルチホームホストにサービスを配置する前に、snoop を使ってサービスが複数のサブネットから出された要求を正確に処理しているかどうかを判断してください。さらに、マルチホームホストに DA を配置することを計画している場合は、DA の配置とスコープ名の割り当て を参照してください。
次の手順に従って、slp.conf ファイルの net.slp.interfaces プロパティを変更します。
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
slpd.conf ファイル内の net.slp.interfaces プロパティを変更します。
net.slp.interfaces=value |
IPv4 アドレスまたはネットワークインタフェースカードのホスト名のリストで、そこに存在する DA や SA はポート 427 上でマルチキャスト、ユニキャスト UDP、および TCP の各メッセージを待機する必要がある
たとえば、3 枚のネットワークカードを持ち、マルチキャストルーティングがオフになっているサーバーが、3 つのサブネットに接続されているとします。その 3 つのネットワークインタフェースの IP アドレスは 192.147.142.42、192.147.143.42、および 192.147.144.42 です。サブネットマスクは 255.255.255.0 です。次のプロパティの設定を行うと、slpd は、3 つすべてのインタフェース上でユニキャストとマルチキャスト/ブロードキャストのメッセージを待機します。
net.slp.interfaces=192.147.142.42,192.147.143.42,192.147.144.42 |
net.slp.interfaces プロパティには、IP アドレスまたは解決可能なホスト名を設定できます。
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
複数のインタフェースを持つホストが slpd およびプロキシ登録を使ってサービスを通知する場合は、slpd によって通知されるサービス URL に到達可能なホスト名またはアドレスが含まれている必要があります。インタフェース間でユニキャストルーティングが有効な場合は、すべてのサブネット上のホストは別のサブネット上のホストに到達できます。任意のサブネット上のサービスに対してプロキシ登録も行うことができます。ただし、ユニキャストルーティングが無効な場合は、1 つのサブネット上のサービスクライアントはマルチホームホストを通じて別のサブネット上のサービスに到達することはできません。ただし、これらのクライアントが別のルーターを通じてサービスに到達できる可能性はあります。
たとえば、デフォルトのホスト名が bigguy のホストが、経路指定されていない異なる 3 つのサブネット上に 3 枚のインタフェースカードを持っているとします。これらのサブネット上のホスト名は、IP アドレス 192.147.142.42 を持つ bigguy、IP アドレス 192.147.143.42 を持つ bigguy1、IP アドレス 192.147.144.42 を持つ bigguy2 です。ここで、レガシープリンタ oldprinter がサブネット 143 に接続され、すべてのインタフェース上で待機するために、URL service:printing:lpr://oldprinter/queue1 が net.slp.interfaces で構成されているとします。oldprinter の URL はすべてのインタフェース上でプロキシ通知されます。サブネット 142 と 144 上のマシンは、サービス要求に対する応答でこの URL を受信しますが、oldprinter サービスにアクセスすることはできません。
この問題の解決方法は、マルチホームホスト上ではなく、サブネット 143 だけに接続されたマシン上で動作している slpd を使ってプロキシ通知を行うことです。サブネット 143 上のホストだけがサービス要求に対する応答でこの通知を取得できます。
マルチホームホストを持つネットワーク上でDA の配置とスコープ名の割り当てを行う場合は、クライアントがアクセス可能なサービスを確実に取得できるように注意してください。経路指定が無効で net.slp.interfaces プロパティが構成されている場合は特に注意してください。また、マルチホームマシン上のインタフェース間でユニキャストルーティングが有効な場合は、特別な DA やスコープを構成する必要はありません。これは、DA にキャッシュされている通知が任意のサブネットからアクセス可能なサービスを識別するためです。ただし、ユニキャストルーティングが無効な場合は、DA をうまく配置しないと問題になることがあります。
前述の例で何が問題になりうるかを見るために、bigguy が DA を実行し、すべてのサブネット上のクライアントが同じスコープを持つ場合に何が起こるかを考えてみます。サブネット 143 上の SA はサービス通知を DA に登録します。サブネット 144 上の UA は、サブネット 143 上のホストに到達できなくても、それらのサービス通知を入手できます。
この問題の 1 つの解決方法は、マルチホームホスト上ではなく、各サブネット上で DA を実行することです。この場合は、マルチホームホスト上の net.slp.interfaces プロパティを、単一のインタフェースホスト名またはアドレスを使って構成するか、構成しないでそのままにし、強制的にデフォルトのインタフェースを使用するようにします。この解決方法の欠点は、通常大規模なマシンであり、DA として高機能であるマルチホームホストを DA に設定できないことです。
もう 1 つの解決方法は、マルチホームホスト上で DA を実行するが、各サブネット上の SA および UA が異なるスコープを持つようにスコープを構成することです。たとえば、前述の場合、142 サブネット上の UA と SA がスコープ scope142 を持つようにスコープを構成することができます。143 サブネット上の UA と SA は、scope143 という別のスコープを持ち、144 サブネット上の UA と SA は scope144 という別のスコープを持つように構成することができます。3 つのインタフェースを持つ bigguy 上の net.slp.interfaces プロパティを構成して、DA を 3 つのサブネット上の 3 つのスコープに作用させることができます。
net.slp.interfaces プロパティを構成すると、マルチホームホスト上の DA がサブネット間のサービス通知をブリッジできるように設定できます。このような構成は、ネットワークでマルチキャストルーティングがオフで、マルチホームホスト上のインタフェース間でユニキャストルーティングが有効な場合に便利です。ユニキャストはインタフェース間を経路指定しているため、サービスが置かれているサブネットと異なるサブネット上のホストは、サービス URL を受信すればそのサービスに接続することができます。DA がない場合は、特定のサブネット上の SA サーバーが同じサブネット上に出されたブロードキャストだけを受信するので、そのサブネット以外にサービスを置くことはできません。
net.slp.interfaces プロパティの構成が必要な場合は、マルチキャストがネットワークに配置されておらず、代わりにブロードキャストが使用されている場合です。その他の場合は、不必要な応答の重複や到達できないサービスを避けるために、入念に検討および計画を行ってください。
レガシーサービスとは、SLP の開発および実装が旧式になっているネットワークサービスのことです。たとえば、ラインプリンタデーモン (lpsched)、NFS ファイルサービス、NIS または NIS+ ネームサービスなどの Solaris サービスは、SLP で使用する内部 SA を持っていません。この章では、レガシーサービスを通知する場合とその方法について説明します。
レガシーサービス通知では、SLP UA を使用可能にすることで、ネットワーク上の次のようなデバイスやサービスを検出できます。
SLP SA を含まないハードウェアデバイスやソフトウェアサービス。たとえば、SLP UA を持つアプリケーションが、SLP SA を含まないプリンタやデータベースを検出する必要がある場合、レガシー通知が必要になります。
レガシーサービスは、次の方法で通知できます。
ソフトウェアサーバーのソースコードを使用できる場合は、SLP SA を組み込むことができます。SLP 用の C 言語の API と Java の API は比較的簡単に使用できます。C 言語の API のマニュアルページと Java の API のマニュアルを参照してください。サービスがハードウェアデバイスの場合は、製造元が SLP を組み込む PROM を更新していることがあります。詳細は、デバイスの製造元に問い合わせてください。
ソースコードや更新された SLP を含む PROM が使用できない場合は、SLP クライアントライブラリを使ってサービスを通知する小さなアプリケーションを書くことができます。このアプリケーションは小さなデーモンとして機能し、サービスの起動・停止に使用する場合と同じシェルスクリプトで起動・停止します。
Solaris の slpd は、プロキシ登録ファイルを使用したレガシーサービスの通知をサポートしています。プロキシ通知ファイルは、移植性のあるフォーマットで書かれたサービス通知のリストです。
ホストのファイルシステムまたは HTTP でアクセス可能なネットワーク上の任意のディレクトリに、プロキシ登録ファイルを作成します。
サービスについてサービスタイプのテンプレートが存在するかどうかを確認します。
テンプレートは、サービスタイプのサービス URL と属性を記述したものです。テンプレートを使用して、特定のサービスタイプについて通知の構成要素を定義します。
サービスタイプテンプレートが存在する場合は、そのテンプレートを使ってプロキシ登録を構成してください。サービスタイプテンプレートについては、RFC 2609 を参照してください。
サービスについてサービスタイプテンプレートを使用できない場合は、サービスを正確に記述する属性の集合体を選択してください。通知に対して、デフォルト以外の命名権限を使用してください。デフォルトの命名権限は標準化されたサービスタイプについてだけ許可されています。命名権限については、RFC 2609 を参照してください。
たとえば、BizApp という会社にソフトウェアバグの追跡に使用されるローカルデータベースがあるとします。データベースを通知するために、この会社は、サービスタイプ service:bugdb.bizapp を持つ URL を使用します。この場合、命名権限は bizapp になります。
前の手順で作成した登録ファイルの場所を使用して、/etc/inet/slp.conf ファイルの net.slp.serializedRegURL プロパティを構成するには、以下の手順に従います。
スーパーユーザーになります。
ホスト上の slpd とすべての SLP 動作を停止します。
# /etc/init.d/slpd stop |
/etc/inet/slp.conf ファイルの net.slp.serializedRegURL プロパティにプロキシ登録の場所を指定します。
net.slp.net.slp.serializedRegURL=proxy registration file URL |
たとえば、直列化登録ファイルが /net/inet/slp.reg である場合、プロパティを次に示すように構成します。
net.slp.serializedRegURL=file:/etc/inet/slp.reg |
変更を保存し、ファイルを閉じます。
変更を反映するには、slpd を再起動します。
# /etc/init.d/slpd start |
サービス通知は、サービス URL を特定する行、オプションのスコープ行、一連の属性の定義から構成されます。SLP デーモンはファイルからプロキシ通知を読み、その通知を登録し、SA クライアントと同じようにそれらを保持します。次のリストは、プロキシ登録ファイルの例を示します。
この例では、LPR プロトコルをサポートするレガシープリンタと ftp サーバーが通知されています。行番号は説明のために付け加えたもので、実際のファイルには記述されていません。
1#Advertise legacy printer. 2 3service:lpr://bizserver/mainspool,en,65535 4scope=eng,corp 5make-model=Laserwriter II 6location-description=B16-2345 7color-supported=monochromatic 8fonts-supported=Courier,Times,Helvetica 9 10 9 10#Advertise FTP server 11 12ftp://archive/usr/src/public,en,65535,src-server 13content=Source code for projects 14 |
プロキシ登録ファイルは、ASCII でない文字のエスケープに、構成ファイルと同じ取り決めを使用します。プロキシ登録ファイルのフォーマットについては、RFC 2614 を参照してください。
通常、SLP を追加する場合、他のサービスの代理として SLP API で通知する SLP 対応のサービスを書くよりも、ソースコードを変更する方が望ましい方法です。ソースコードの変更は、プロキシ登録を使用するよりも望ましい方法です。ソースコードを変更する場合、サービス固有の機能を追加したり、サービスの使用可否を綿密に追跡したりできます。ソースコードが使用できない場合は、プロキシ登録を使用するより他のサービスの代理として通知する SLP 対応のヘルパーサービスを書く方が望ましい方法です。このヘルパーサービスを、起動と停止の制御に使用されるサービスの開始または停止手順に組み込むことをお勧めします。プロキシ通知は通常、ソースコードが使用できず、スタンドアロンの SA を書くことが実際的ではない場合の 3 番目の選択肢です。
プロキシ通知は、プロキシ登録ファイルを読み取る slpd が動作している間だけ保持されます。プロキシ通知とサービスの間には直接的な関係はありません。通知がタイムアウトしたり slpd が停止したりすると、プロキシ通知は使用できなくなります。
サービスが停止した場合は、slpd を停止する必要があります。直列化登録ファイルを編集してプロキシ通知をコメントにするか削除し、slpd を再起動してください。サービスを再起動または再インストールしたときは同じ手順に従ってください。プロキシ通知とサービスの間に関係のないことがプロキシ通知の主な欠点です。
この章では、SLP のステータスコードとメッセージタイプについて説明します。SLP のメッセージタイプは、省略形と機能コードを示します。SLP のステータスコードは、説明と機能コードを示します。ステータスコードは、該当する要求を受信しているか (コード 0)、受信側がビジーであるかを示します。
SLP デーモン (slpd) は、ユニキャストメッセージに対してだけステータスコードを返します。
ステータスのタイプ |
ステータスコード |
説明 |
---|---|---|
No Error |
0 |
要求はエラーなしで処理された |
LANGUAGE_NOT_SUPPORTED |
1 |
AttrRqst または SrvRqst について、スコープ内にサービスタイプのデータがあるが、指定された言語ではない |
PARSE_ERROR |
2 |
メッセージが SLP 構文に従っていない |
INVALID_REGISTRATION |
3 |
SrvReg に問題がある。たとえば、有効期限がゼロである、言語タグが欠けているなど |
SCOPE_NOT_SUPPORTED |
4 |
SLP メッセージが、要求に応える SA または DA がサポートするスコープリスト内のスコープを含んでいなかった |
AUTHENTICATION_UNKNOWN |
5 |
DA または SA がサポートしていない SLP SPI に対する要求を受信した |
AUTHENTICATION_ABSENT |
6 |
UA または DA が SrvReg において URL および属性認証を要求したが受信しなかった |
AUTHENTICATION_FAILED |
7 |
UA または DA が認証ブロックにおいて認証エラーを検出した |
VER_NOT_SUPPORTED |
9 |
メッセージでサポートしていないバージョン番号 |
INTERNAL_ERROR |
10 |
DA または SA で未知のエラーが発生した。たとえば、オペレーティングシステムがファイルスペースを使い果たした |
DA_BUSY_NOW |
11 |
UA または SA は、急増するバックオフを使用して再試行する必要がある。DA が他のメッセージの処理でビジー状態である |
OPTION_NOT_UNDERSTOOD |
12 |
DA または SA が必須の範囲から未知のオプションを受信した |
INVALID_UPDATE |
13 |
DA が登録されていないサービスに対して、FRESH 設定なしで、あるいは矛盾するサービスタイプで、SrvReg を受信した |
MSG_NOT_SUPPORTED |
14 |
SA が AttrRqst または SrvTypeRqst を受信したが、サポートしていない |
REFRESH_REJECTED |
15 |
SA が DA に対して、DA の最短更新間隔よりも頻繁に SrvReg または SrvDereg の一部を送った |
メッセージタイプ |
省略形 |
機能コード |
説明 |
---|---|---|---|
サービス要求 |
SrvRqst |
1 |
サービスを検出するために UA が発行する。あるいは、能動的 DA 検出において UA あるいは SA サーバーが発行する |
サービス応答 |
SrvRply |
2 |
DA あるいは SA がサービス要求に対して応答する |
サービス登録 |
SrvReg |
3 |
SA が新規の通知を登録したり、既存の通知を新規の属性および変更された属性で更新したり、URL の有効期限を更新できるようにしたりする |
サービス登録解除 |
SrvDereg |
4 |
表しているサービスが無効になった場合にその通知の登録を解除するために SA が使用する |
確認応答 |
SrvAck |
5 |
SA のサービス要求またはサービス登録解除メッセージに対する DA の応答 |
属性要求 |
AttrRqst |
6 |
URL またはサービスタイプが作成し、属性のリストを要求する |
属性応答 |
AttrRply |
7 |
属性のリストを返す場合に使用される |
DA 通知 |
DAAdvert |
8 |
サービス要求をマルチキャストするための DA の応答 |
サービスタイプ要求 |
SrvTypeRqst |
9 |
特定の命名権限を持ち、特定のスコープセットにある登録されたサービスタイプについて問い合わせるために使用される |
サービスタイプ応答 |
SrvTypeRply |
10 |
サービスタイプ要求に対する応答として返されるメッセージ |
SA 通知 |
SAAdvert |
11 |
DA が配置されていないネットワークで、UA は SAAdvert を使用して SA およびそのスコープを検出する |