OpenSLP とは
SLP とは Service Location Protocol の略で、ネットワークサービスの探索や選択を柔軟に提供するネットワークプロトコルです。
現在のバージョンは、1999 年に RFC2608 で定められた [バージョン 2] です。
マルチキャストによる探索などで UDP が使われますが、リクエスト/リプライ等で TCP も使われます。Welknown ポート番号は 427 です。
SLP にはいくつかの実装がありますが、そのうちの 1 つが、オープンソースの OpenSLP です。
後述しますが、VMware の CIM 等で OpenSLP が使われています。
SLP の概要とシーケンス
SLP では大きく3つの機能に分かれています。
- User Agent (UA) : サービスの場所を探す
- Service Agent (SA) : 1つ以上のサービスの場所を応答する
- Directory Agent (DA) : SA が持っているサービス情報を集めるキャッシュレポジトリ
User Agent は Serivce Agent と同一セグメントに存在するときは、マルチキャスト (もしくはブロードキャスト) で探索することができます。Service Agent からはユニキャストで返信され、その中にサービスのロケーション の URL が含まれることになります。
URL は、純粋にプロトコルを使うだけなのであれば "service:http://ok.example.com" といった形式で登録しますが、「これをするために http を使いたい」というとき、例えば印刷をするために http を使いたい、というときには "service:printer:http://ok.example.com" といった形式で登録も可能です。(上図の例では service:printer:lpr:// ですが)
さて、小規模のネットワークであれば、上図のように Service Agent と User Agent を同一セグメントに配置して利用すればよいでしょうが、大規模のエンタープライズネットワークの場合はどうすべきでしょうか。
Directory Agent を導入すると、各 Service Agent は Directory Agent にサービスロケーション情報を登録することができます。また、User Agent は Directory Agent へ接続し、各種サービスロケーション情報を取得することができます。
では Directory Agent の IP はどのように探すのでしょうか。単純に手動設定という手もありますが、やはりマルチキャストで検知することができます。検知は要求に応じて返信するパターンと、勝手に広告するパターンの 2 パターンがあります。
VMware での OpenSLP の実装
VMware では CIM (Common Information Model) という「ハードウェア情報を収集するためのサービス」の位置情報取得を OpenSLP で実装しています。
ESXi ホストは CIM プロバイダとして ESXi ホストのハードウェア管理情報を監視/管理サーバなどに提供しますが、提供用の URL を SLP 経由で取得できます。つまり、ESXi ホストは CIM プロバイダであり、SLP Service Agent となります。加えて、自分自身が Directory Agent となり、自分のサービスをキャッシュします。
そして富士通の Server View や NEC の ESMPRO, HP Insight Manager 等の監視/管理サーバが CIM ブローカとしてハードウェア情報を収集できますので、これらのサーバ監視サーバが SLP User Agent となります。
DNS SRVレコードとの違い
SLP は仕組みとしては DNS SRV と似ています。
RFC3832 では DNS の SRV レコードを使って、OpenSLP の Directory Agent の IP を取得しよう、という試みが記されています。(RFC は Experimental、つまり「実験的」という位置付けです)
序文 (1. Introduction) には以下のように記載されています。
DNS SRV provides good support for remote service discovery. However, if multiple servers are discovered via DNS SRV for a service, only priority and weight can be used to make a selection. If additional service properties (such as cost, speed and service quality) need to be considered in the selection process, DNS SRV becomes insufficient.
日本語訳すると以下のようになります。
DNS SRV はリモートサービスディスカバリのための良いサポートを提供します。しかし、複数のサーバが1つのサービスをDNS SRVでディスカバリされた場合、優先度と重みだけが選択基準となります。もし他のサービスプロパティ(コストや速度、サービス品質など) が選択プロセスで考慮必要であれば、DNS SRVでは不十分です。
サービス選択においては SLP が有利だけど、SLP の Directory Agent の IP は別セグメントだと自動取得できないから、DNS SRV レコードで SLP Directory Agent を探してしまおう、という主旨です。
実際、SLP では SRV レコード以上に柔軟なサービス情報取得が可能であり、活用シーンの幅は広いです。
例えば OpenSLP のサイトでは以下のような事例が紹介されています。
[Traditional]
Newbie: "Hey Stan, the setup program is asking me for the name of our printer. What should I type in?"
Stan: "Which printer do you want?"
Newbie: "The big one by the copier."
Stan: "I've heard it doesn't work well with postscript applications. You'll have to use the one down the hall."
Newbie: "Ok. What should I type in."
Stan: "Actually, I don't know; I use the one by the copier. You'll probably have to call the IS help desk."
Newbie: ...
[With SLP]
A setup program uses SLP to display to the user the description (including location) of the printers that work with postscript. The user selects one that is close to his office. The SLP service returns all necessary addressing information directly to his device setup application.
つまりどういうことかというと、今まではプリンタのセットアッププログラムでホスト名や IP 等を指定しなければならなかったのが、SLP を導入することで、セットアッププログラム (with SLP User Agent) が SLP Directory Agent に接続しにいき、適切な情報を取得、表示し、ユーザは自分の席の近くのプリンタを画面上でクリックすればセットアップが完了する、といったものです。
また、SLP には scope や tag といった追加情報を付加することができ、これに応じて適切な応答を返す、といったことができます。
例えば User Agent が「scope=営業部」とした場合は営業部用のプリンタの URL を、「scope=開発部」とした場合は開発部用のプリンタの URL を返すことができます。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント