この章では、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 プロパティの構成が必要な場合は、マルチキャストがネットワークに配置されておらず、代わりにブロードキャストが使用されている場合です。その他の場合は、不必要な応答の重複や到達できないサービスを避けるために、入念に検討および計画を行ってください。