test

Solaris のシステム管理 (資源管理とネットワークサービス)

第 20 章 SLP の管理 (手順)

この章では、SLP のエージェントとプロセスを構成するための情報と作業手順について説明します。

SLP プロパティの構成

SLP 構成プロパティは、ネットワークの相互作用、SLP エージェントの特性、状態、およびログを制御します。ほとんどの場合、これらのプロパティのデフォルトの構成は変更する必要がありません。ただし、ネットワークの媒体またはトポロジが変更される場合は、次の目的を達成するためには、この章の手順を使用します。

SLP 構成ファイル /etc/inet/slp.conf を編集して、次の表に示す処理を行うことができます。

表 20–1 SLP 構成の操作

操作 

説明 

slpd が DA サーバーと SA サーバーのどちらで機能するかを指定する。SA サーバーがデフォルト

net.slpisDA プロパティに True を設定する

マルチキャストメッセージのタイミングを設定する 

net.slp.DAHeartBeat プロパティを設定して、請求されていない DA 通知を DA がマルチキャストする回数を制御する

DA ロギングを使用可能にしてネットワークトラフィックを監視する 

net.slp.traceDATraffic プロパティに True を設定する

SLP 構成ファイルの基本要素

/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 が使用できるクライアントまたはサービスソフトウェアは、SLP API を使用して、SLP 構成も変更できます。API については、Internet Engineering Task Force (IETF) 発行の『An API for Service Location, RFC 2614』を参照してください。(http://www.ietf.org/rfc/rfc2614.txt )

  1. スーパーユーザーになります。

  2. ホスト上の slpd とすべての SLP 動作を停止します。 


    # /etc/init.d/slpd stop

  3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

  4. 必要に応じて、/etc/inet/slp.conf ファイルのプロパティ設定を編集します。

    SLP プロパティの設定については、構成プロパティ を参照してください。slp.conf プロパティを変更する別の例については、後述の各節を参照してください。slp.conf(4) のマニュアルページを参照してください。

  5. 変更を保存し、ファイルを閉じます。

  6. 変更を反映するには、slpd を再起動します。


    # /etc/init.d/slpd start
注 –

slpd を停止または起動するとき、SLP デーモンは構成ファイルから情報を取得します。

たとえば、slpd.conf ファイルの net.slp.isDA プロパティに True を設定して、slpd が DA サーバーとして動作するように SA サーバーのデフォルトを変更できます。


net.slp.isDA=True

各領域で、各種のプロパティが構成の異なる場合を制御します。以降の各節では、SLP 構成で使用するデフォルトのプロパティ設定を変更するさまざまなシナリオについて説明します。

DA 通知と検出頻度の変更

次のような場合は、DA 通知と検出要求のタイミングを制御するプロパティを変更できます。

この節の手順では、次のプロパティを変更する方法について説明します。

表 20–2 DA 通知タイミングと検出要求のプロパティ

プロパティ  

説明 

net.slp.passiveDADetection

請求されていない DA 通知を slpd が受信するかどうかを示すブール値

net.slp.DAActiveDiscoveryInterval

slpd が、新しい DA に対して DA の能動的検出を実行する頻度を示す値

net.slp.DAHeartBeat

請求されていない DA 通知を DA がマルチキャストする頻度を示す値 

UA と SA を静的に構成された DA に限定する

UA と SA が slp.conf ファイル内の静的な構成情報から DA アドレスだけを取得するように制限することが必要な場合があります。次の手順では、slpd が net.slp.DAAddresses プロパティから DA 情報だけを取得するように 2 つのプロパティを変更できます。

UA と SA を静的に構成された DA に限定する方法

次の手順に従って、net.slp.passiveDADetection および net.slp.DAActiveDiscoveryInterval プロパティを変更します。

注 –

この手順は、静的な構成を使用するように制限されている UA と SA を実行するホストにだけ使用してください。

  1. スーパーユーザーになります。

  2. ホスト上の slpd とすべての SLP 動作を停止します。


    # /etc/init.d/slpd stop

  3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

  4. slp.conf ファイル内の net.slp.passiveDADetection プロパティに False を設定して、受動的検出を無効にします。この設定により、slpd は請求されていない DA 通知を無視します。 


    net.slp.passiveDADetection=False

  5. net.slp.DAActiveDiscoveryInterval に -1 を設定して、初期および定期の能動的検出を無効にします。 


    net.slp.DAActiveDiscoveryInterval=-1

  6. 変更を保存し、ファイルを閉じます。

  7. 変更を反映するには、slpd を再起動します。


    # /etc/init.d/slpd start

ダイアルアップネットワークに対する DA 検出の構成

UA または SA がダイアルアップネットワークによって DA から切り離されている場合は、DA 検出を構成して、検出要求と DA 通知の数を削減するか、完全になくすことができます。ダイアルアップネットワークでは、通常起動時に課金されます。余分な通話を最小限に抑えることにより、ダイアルアップネットワークの使用コストを削減できます。

注 –

UA と SA を静的に構成された DA に限定する で説明している方法で、DA 検出を完全に無効にすることができます。

ダイアルアップネットワークに対する DA 検出の構成方法

次の手順に従って、DA ハートビートの期間と能動的検出の間隔を長くすることで、請求されていない DA 通知と能動的検出を削減できます。

  1. スーパーユーザーになります。

  2. ホスト上の slpd とすべての SLP 動作を停止します。


    # /etc/init.d/slpd stop

  3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

  4. slpd.conf ファイル内の net.slp.DAHeartbeat プロパティの値を大きくします。


    net.slp.DAHeartbeat=value

    value

    32 ビットの整数で、DA 通知の受動的ハートビートに対して秒数を設定する 

    デフォルト値は、10800 秒 (3 時間) 

    値の範囲は、2000 から 259200000 秒 

    たとえば、DA を実行しているホストに対して、DA のハートビートを約 18 時間に設定できます。


    net.slp.DAHeartbeat=65535

  5. slpd.conf ファイル内の net.slp.DAActiveDiscoveryInterval プロパティの値を大きくします。


    net.slp.DAActiveDiscoveryInterval value

    value

    32 ビットの整数で、DA の能動的検出クエリーに対して秒数を設定する 

    デフォルトの値は、900 秒 (15 分) 

    値の範囲は、300 から 10800 秒 

    たとえば、UA と SA を実行しているホストに対して、DA の能動的検出の間隔を 18 時間に設定できます。


    net.slp.DAActiveDiscoveryInterval=65535

  6. 変更を保存し、ファイルを閉じます。

  7. 変更を反映するには、slpd を再起動します。


    # /etc/init.d/slpd start

頻繁なパーティション分割に対する DA のハートビートの構成

スコープをサポートするすべての 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 がパーティションの修正後にキャッシュに復元されるまでの遅延時間を縮小できます。

頻繁なパーティション分割に対して DA のハートビートを構成する方法

次の手順に従って、net.slp.DAHeartBeat プロパティを変更し、DA のハートビート期間を短くします。

  1. スーパーユーザーになります。

  2. ホスト上の slpd とすべての SLP 動作を停止します。


    # /etc/init.d/slpd stop

  3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

  4. DA のハートビートの値を 1 時間 (3600 秒) に縮小します。デフォルトでは、DA のハートビート期間は 3 時間 (10800 秒) に設定されています。 


    net.slp.DAHeartBeat=3600

  5. 変更を保存し、ファイルを閉じます。

  6. 変更を反映するには、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 のパフォーマンスを調整する場合の可能なシナリオについて説明します。

表 20–3 SLP パフォーマンスのプロパティ

プロパティ  

説明 

net.slp.DAAttributes

DA が通知を受け取る最短の更新間隔 

net.slp.multicastTTL

マルチキャストパケットの有効期限

net.slp.MTU

ネットワークパケットのサイズ (バイト)。サイズには、IP と TCP または UDP の各ヘッダーが含まれている 

net.slp.isBroadcastOnly

ブロードキャストを DA サービス検索および DA ベースでないサービス検索に使用する必要があるかどうかを示すために設定されるブール値 

SA 再登録の削減

SA は、期限が切れる前に定期的にサービス通知を更新する必要があります。DA が多くの UA と SA の非常に重い負荷を処理している場合は、頻繁な更新により DA が過負荷になることがあります。DA が過負荷になると、UA の要求がタイムアウトして欠落します。UA 要求のタイムアウトには多くの原因が考えられます。DA の過負荷が問題であると仮定する前に、snoop トレースを使ってサービス登録に登録されているサービス通知の有効期限を確認してください。有効期限が短く、再登録が頻繁に発生している場合は、再登録が頻繁すぎることがタイムアウトの原因と考えられます。

注 –

サービス登録は、FRESH フラグが設定されていなければ再登録になります。サービス登録メッセージについては、第 22 章「SLP (リファレンス)」を参照してください。

SA 再登録を削減する方法

次の手順に従って、SA の最小更新間隔を長くすることで、再登録回数を削減します。

  1. スーパーユーザーになります。

  2. ホスト上の slpd とすべての SLP 動作を停止します。 


    # /etc/init.d/slpd stop

  3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

  4. net.slp.DAAttributes プロパティの min-refresh-interval 属性の値を大きくします。

    デフォルトの最短再登録期間はゼロ (0) です。デフォルトがゼロの場合、SA はいつでも自由に再登録できます。次の例では、間隔は 3600 秒 (1 時間) に増やしています。


    net.slp.DAAttributes(min-refresh-interval=3600)

  5. 変更を保存し、ファイルを閉じます。

  6. 変更を反映するには、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 プロパティを設定し直します。

  1. スーパーユーザーになります。

  2. ホスト上の slpd とすべての SLP 動作を停止します。


    # /etc/init.d/slpd stop

  3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

  4. slpd.conf ファイル内の net.slp.multicastTTL プロパティを変更します。


    net.slp.multicastTTL=value

    value

    マルチキャスト TTL を定義する 255 以下の正の整数 

    注 –

    TTL 値を減らしてマルチキャストの伝達範囲を縮小することができます。TTL の値が 1 の場合、パケットはそのサブネットに限定されます。TTL の値が 32 の場合は、パケットはそのサイトに限定されます。「サイト」は、マルチキャスト TTL について記述されている RFC 1075 では定義されていません。32 以上の値は、インターネット上の論理的な経路を指すので使用しないでください。32 未満の値は、各ルーターが TTL で正しく構成されていれば、マルチキャストをアクセス可能なサブネットのセットに限定するために使用できます。

  5. 変更を保存し、ファイルを閉じます。

  6. 変更を反映するには、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 プロパティを調整することで、デフォルトのパケットサイズを変更します。

  1. スーパーユーザーになります。

  2. ホスト上の slpd とすべての SLP 動作を停止します。


    # /etc/init.d/slpd stop

  3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

  4. slpd.conf ファイル内の net.slp.MTU プロパティを変更します。


    net.slp.MTU=value

    value

     

    16 ビットの整数で、ネットワークのパケットサイズ (バイト単位) 

    デフォルト値は、1400  

    値の範囲は、128 から 8192 

  5. 変更を保存し、ファイルを閉じます。

  6. 変更を反映するには、slpd を再起動します。


    # /etc/init.d/slpd start

ブロードキャスト専用ルーティングの構成

SLP は、DA が存在しない場合に、マルチキャストを使ってサービス検出や DA 検出を行うように設計されています。使用するネットワークが、マルチキャストルーティングを配置しない場合は、net.slp.isBroadcastOnly プロパティに True を設定することで、SLP がブロードキャストを使用するように構成できます。

マルチキャストと異なり、ブロードキャストパケットはデフォルトの場合サブネットを越えて伝達しません。このため、マルチキャストを行わないネットワークでは、DA を使用しないサービス検出は、単一のサブネット上でしか機能しません。さらに、ブロードキャストが使用されているネットワークに DA およびスコープを配置する場合は、特別な考慮が求められます。マルチホームホスト上の DA は、マルチキャストが使用できない複数のサブネット間でサービス検出をブリッジできます。マルチホームホスト上の DA の配置については、DA の配置とスコープ名の割り当て を参照してください。

ブロードキャスト専用ルーティングの構成方法

次の手順に従って、net.slp.isBroadcastOnly プロパティを True に変更します。

  1. スーパーユーザーになります。

  2. ホスト上の slpd とすべての SLP 動作を停止します。 


    # /etc/init.d/slpd stop

  3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

  4. slpd.conf ファイル内の net.slp.isBroadcastOnly プロパティを True に変更します。


    net.slp.isBroadcastOnly=True

  5. 変更を保存し、ファイルを閉じます。

  6. 変更を反映するには、slpd を再起動します。


    # /etc/init.d/slpd start

SLP 検出要求のタイムアウトの変更

SLP 検出要求のタイムアウトを変更する必要があるのは、次の 2 つの場合です。

デフォルトのタイムアウトの変更

ネットワークの応答時間が長いと、UA および SA が要求と登録を行う場合、応答を受け取る前にタイムアウトになる原因になります。複数のサブネット、ダイアルアップ回線、または WAN によって UA が SA から切り離されている場合、または UA と SA の両方が DA から切り離されている場合、応答時間が問題となることがあります。応答時間が問題であるかどうかを判断するには、UA および SA の要求と登録でタイムアウトが起こったために SLP 要求が失敗しているかどうかを確認します。ping コマンドを使って実際の応答時間を測定することもできます。

次の表は、タイムアウトを制御する構成プロパティを示します。この節で説明する手順で、これらのプロパティを変更できます。

表 20–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 プロパティを変更します。

  1. スーパーユーザーになります。

  2. ホスト上の slpd とすべての SLP 動作を停止します。


    # /etc/init.d/slpd stop

  3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

  4. slpd.conf ファイル内の net.slp.multicastMaximumWait プロパティを変更します。


    net.slp.multicastMaximumWait=value

    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

  5. slpd.conf ファイル内の net.slp.datagramTimeouts プロパティを必要に応じて変更します。


    net.slp.datagramTimeouts=value

    value

    32 ビット整数のリストで、ユニキャストのデータグラム転送を DA に実行するためのタイムアウト (ミリ秒) 

    デフォルト値は、3000,3000,3000 

    たとえば、頻繁なタイムアウトの発生を回避するために、データグラムのタイムアウトを 20000 ミリ秒に増やすことができます。


    net.slp.datagramTimeouts=2000,5000,6000,7000

    高パフォーマンスのネットワークでは、逆に UDP データグラム転送のマルチキャストまたはユニキャストのタイムアウトの上限を小さくできます。 タイムアウトの上限を小さくすることで、SLP 要求を満たすために必要な応答時間を短縮できます。

  6. 変更を保存し、ファイルを閉じます。

  7. 変更を反映するには、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 プロパティを変更します。

  1. スーパーユーザーになります。

  2. ホスト上の slpd とすべての SLP 動作を停止します。


    # /etc/init.d/slpd stop

  3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

  4. slpd.conf ファイル内の net.slp.RandomWaitBound プロパティを変更します。


    net.slp.RandomWaitBound=value

    value

    DA に接続するまでのランダム待ち時間の計算に使用される上限 

    デフォルト値は、1000 ミリ秒 (1 秒) 

    値の範囲は、1000 から 3000 ミリ秒  

    たとえば、ランダム待ち時間を 5000 ミリ秒 (5 秒) に延長できます。


    net.slp.randomWaitBound=5000

    ランダム待ち時間の上限を長くすると、登録で遅延が長くなります。SA は新しく検出された DA をより時間をかけて登録できるので、衝突とタイムアウトを回避することができます。

  5. slpd.conf ファイル内の net.slp.datagramTimeouts プロパティを必要に応じて変更します。


    net.slp.datgramTimeouts=value

    value

    32 ビット整数のリストで、ユニキャストのデータグラム転送を DA に実行するためのタイムアウト (ミリ秒) 

    デフォルト値は、3000,3000,3000 

    たとえば、頻繁なタイムアウトの発生を回避するために、データグラムのタイムアウトを 20000 ミリ秒に増やすことができます。


    net.slp.datagramTimeouts=2000,5000,6000,7000

    高パフォーマンスのネットワークでは、逆に UDP データグラム転送のマルチキャストまたはユニキャストのタイムアウトの上限を小さくできます。 この設定により、SLP 要求を満たす際に、応答時間を短縮できます。

  6. 変更を保存し、ファイルを閉じます。

  7. 変更を反映するには、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 プロパティに追加します。

  1. スーパーユーザーになります。

  2. ホスト上の slpd とすべての SLP 動作を停止します。


    # /etc/init.d/slpd stop

  3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

  4. slpd.conf ファイル内の net.slp.useScopes プロパティを変更します。


    net.slp.useScopes=<scope names>

    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

  5. 変更を保存し、ファイルを閉じます。

  6. 変更を反映するには、slpd を再起動します。


    # /etc/init.d/slpd start

DA の配置

この節では、SLP を実行しているネットワークでの計画的な DA の配置について説明します。

配置された DA または構成されたスコープがなくても、基本のエージェントである UA と SA だけで SLP は十分機能します。特定の構成を持たないすべてのエージェントは自動的に default スコープを使用します。DA はサービス通知のキャッシュとして機能します。DA を配置すると、ネットワークに送られるメッセージ数が削減されるため、メッセージ応答の受け取りに必要な時間も短縮されます。これにより、SLP をより大規模なネットワークに対応させることができます。

SLP DA を配置する理由

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 を配置する場合

次の条件のどれかに当てはまる場合は、エンタープライズに DA を配置します。

DA を配置する方法

次の手順に従って、slp.conf ファイルの net.slp.isDA プロパティに True を設定します。

注 –

1 台のホストにつき 1 つの DA だけが割り当てられます。

  1. スーパーユーザーになります。

  2. ホスト上の slpd とすべての SLP 動作を停止します。


    # /etc/init.d/slpd stop

  3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

  4. slpd.conf ファイル内の net.slp.isDA プロパティに True を設定します。


    net.slp.isDA=True

  5. 変更を保存し、ファイルを閉じます。

  6. 変更を反映するには、slpd を再起動します。


    # /etc/init.d/slpd start

DA を配置する場所

この節は、DA を配置する場所について状況ごとにヒントを示します。

複数の DA を配置して負荷を均等にする

負荷を均等にする手段として、同じスコープの集合体について複数の DA を配置できます。次の状況のどれかに当てはまれば、DA を配置できます。

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 に設定することによって構成します。

経路指定されていない複数のネットワークインタフェースの構成 (作業マップ)

表 20–5 経路指定されていない複数のネットワークインタフェースの構成

タスク 

説明 

参照先 

net.slp.interfaces プロパティを構成する

このプロパティを設定することで、slpd は、指定されたインタフェース上でユニキャストとマルチキャスト/ブロードキャストの SLP 要求を待機できる

net.slp.interfaces プロパティの構成

サブネット上の UA が到達可能なアドレスを持つサービス URL を取得できるように、プロキシサービス通知を配置する 

マルチホームホストではなく単一のサブネットに接続された slpd を実行しているマシンにプロキシ通知を限定する

マルチホームホスト上のプロキシ通知

UA と SA 間で確実に到達できるように DA を配置してスコープを構成する 

マルチホーム上の net.slp.interfaces プロパティを単一インタフェースのホスト名またはアドレスで構成する。

マルチホームホスト上で DA を実行し、各サブネット上の SA と UA は別のホストを使用するように構成する 

DA の配置とスコープ名の割り当て

net.slp.interfaces プロパティの構成

net.slp.interfaces プロパティが設定されている場合、slpd は、ユニキャストとマルチキャスト/ブロードキャストの SLP 要求を、デフォルトのインタフェース上ではなく、プロパティにリストされたインタフェース上で待機します。

通常、net.slp.interfaces プロパティを設定すると同時に、net.slp.isBroadcastOnly プロパティも設定することでブロードキャストを有効にします。これは、ネットワークにマルチキャストが配置されていないために行います。ただし、マルチキャストは配置されているが、この特定のマルチホームホスト上で経路指定されていない場合、マルチキャスト要求は、複数のインタフェースから slpd に到達できます。このような状況は、パケットの経路指定が、別のマルチホームホストまたはインタフェースからサービスを受けるサブネットに接続されているルーターによって制御されている場合に起こります。

この場合、SA サーバーまたは要求を送っている UA は、マルチホームの slpd から 2 つの応答を受け取ります。これらの応答はクライアントライブラリによってフィルタにかけられて除かれるので、クライアントには見えません。ただし、この応答は、snoop トレースで見ることができます。

注 –

ユニキャストルーティングがオフになっている場合、マルチホームホスト上の SA クライアントによるサービス通知がすべてのサブネットに到達できないことがあります。サービスが到達できない場合、SA クライアントは次のことを実行できます。

SA クライアントライブラリには、到達可能な URL が確実に通知されるようにするためのしくみはありません。したがって、到達可能な URL が確実に通知されるようにするには、経路指定のないマルチホームホストを処理できるかどうかにかかわらず、サービスプログラムに任せる必要があります。

ユニキャストルーティングが無効なマルチホームホストにサービスを配置する前に、snoop を使ってサービスが複数のサブネットから出された要求を正確に処理しているかどうかを判断してください。さらに、マルチホームホストに DA を配置することを計画している場合は、DA の配置とスコープ名の割り当て を参照してください。

net.slp.interfaces プロパティの構成方法

次の手順に従って、slp.conf ファイルの net.slp.interfaces プロパティを変更します。

  1. スーパーユーザーになります。

  2. ホスト上の slpd とすべての SLP 動作を停止します。


    # /etc/init.d/slpd stop

  3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

  4. slpd.conf ファイル内の net.slp.interfaces プロパティを変更します。


    net.slp.interfaces=value

    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 アドレスまたは解決可能なホスト名を設定できます。

  5. 変更を保存し、ファイルを閉じます。

  6. 変更を反映するには、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 の配置とスコープ名の割り当て

マルチホームホストを持つネットワーク上で 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 つのスコープに作用させることができます。

経路指定されていない複数のネットワークインタフェースを構成する場合の検討事項

マルチホームホスト上の DA がサブネット間のサービス通知をブリッジできるように net.slp.interfaces プロパティを構成することができます。このような構成は、ネットワークでマルチキャストルーティングがオフで、マルチホームホスト上のインタフェース間でユニキャストルーティングが有効な場合に便利です。ユニキャストはインタフェース間を経路指定しているため、サービスが置かれているサブネットと異なるサブネット上のホストは、サービス URL を受信すればそのサービスに接続することができます。DA がない場合は、特定のサブネット上の SA サーバーが同じサブネット上に出されたブロードキャストだけを受信するので、そのサブネット以外にサービスを置くことはできません。

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