サーバ構成¶
SMFv2システムで動作する各サーバの構成を以下の図に示します。
- LS
IIJが管理するLSシステムが動作するサーバです。サービスアダプタにLocation-Configを提供します。
- RS
RS事業者が構築する、サービスアダプタに対する設定・管理を行うためのサーバです。 RS事業者(サービス)毎に複数設置されます。
- ARMS-Proxyサーバ
RSとセットで構築される、ARMSプロトコルの中継サーバです。 RSに代わって直接ARMSプロトコルを用いてサービスアダプタとの通信を行うためのサーバです。
- Heartbeatサーバ
Heartbeatパケットを受信し、死活判定を行うためのサーバです。 RS事業者が必要に応じて構築します。
以下の節で、各サーバの仕様について解説を行います。
Location Server(LS)仕様¶
LSは、サービスアダプタからのrs-solicitationリクエストに対し、適切なRSへの 接続情報を含むレスポンスを返すためのサーバです。 また、Distribution IDの登録や割り当てを行うためのWebインタフェースが提供されており、 RS事業者はIIJからLSサービス申込時に通知されるアカウントを用いてログインを行うことができます。
RSの登録¶
RS事業者は、WebインターフェイスからRSの登録・削除を行うことができます。 RSには任意のラベル名をつけることができます。1つのRS事業者用アカウントで、複数のRSを作成することもできます。
管理者情報の登録¶
作成したRS毎に、管理者情報を登録することができます。登録可能な情報は以下の通りです。
事業社名
住所
担当者または担当部署
電話番号
メールアドレス
これらの情報は、Distribution IDの割り当てに際し、事業者間で調整が必要なときに参照されます。
Distribution IDの登録・割り当て¶
LS上では、ハードウェアベンダによって取得されたDistribution IDが、すべて登録されています。 このDistribution IDは、登録された後、RS事業者によって「割り当て」が行われることにより、Location-Configへの紐づけが行われます。
Distribution IDの登録は、ハードウェアベンダからの登録申請によって行われ ます。なおこの際は
Distribution ID
LS-SAキー
の2つの情報をペアで登録する必要があります。
RS事業者は、LSシステムのWebUIからログインを行うことにより、任意のDistribution IDを、自身のRSに割り当てることができます。 ただし、Distribution IDは1つのRSにのみ割り当てることができますので、 既に他のRS事業者に割り当てられているDistribution IDを勝手に変更することはできません。 この場合、既に割り当てを行っているRS事業者に対し、割り当ての削除を依頼する必要があります。
Distribution IDの割り当ての際には
Distribution ID
RS-SAキー
の2つの情報をペアで登録する必要があります。
RS パラメータ、Location-Configの設定¶
LSシステムのWebUIを用いて、サービスアダプタが取得するLocation-Configと、 RS接続時に用いるリトライパラメータ関連の設定を行うことができます。
この図は、LSシステムのWebUI画面の一部です。
- Layer2タイムアウト時間
PPPoE、DHCPなど、下位レイヤでのアドレス取得に失敗したとみなすまでのタイムアウト時間です。
- RSへの最大リトライ回数
RSへの接続が失敗したときの最大リトライ回数です。
- RSへのリトライ間隔
RSへの接続が失敗したときのリトライ間隔です。
この図は、LSシステムのWebUI画面の一部です。
- RSのURL
RSへの接続先URLを指定します。 実際には、直接RSに接続可能な手段を持つサービスアダプタ用の場合はARMS-Proxyサーバのアドレスを指定することになります。 IIJのアカウントオプションサービスを用い、複数同時接続用のPPPoEアカウントを利用する場合は、 IIJのサーバセグメントに設置されるリレーエージェントのアドレスを指定する必要があります。 (リレーエージェントのアドレスについてはIIJまでお問い合わせください)
- RSへの接続設定
サービスアダプタに実際に投入されるコンフィグの実体となります。 コンフィグとして必要になるのは、RSに接続するために必要な設定(接続に利用するインターフェイス、PPPoEアカウントなど)となります。 設定方法や文法についてはサービスアダプタのコンフィグ書式に依存します。
RS接続設定は、1つのRS登録につき、最大で5個まで設定することが可能です。複数設定した場合の試行順序は、サービスアダプタの実装に依存しています。
rs-solicitation requestへの応答¶
サービスアダプタからのrs-solicitation requestをLSが受信すると、以下の動作を行います。
rs-solicitationが正規のものであるかどうか検証する
HTTP認証に用いられているLS-SAキーが登録されているものと一致すること
Distribution IDが、何らかのRSに割り当てられていることを確認する
割り当てられているRSのLocation-Configを取得し、rs-solicitation レスポンスを生成してサービスアダプタに応答する
このとき、LS-SAキーが一致しなかったり、Distribution IDへの割り当てが行われていない場合は起動処理が正常に完了しません。
Resource Server(RS)仕様¶
RSは、サービスアダプタに対するコンフィグの提供、リモートオペレーション、 監視といった各種のオペレーションを行うことができる、SMFv2システムにおける中心的な役割を果たすサーバです。
RSは、LSサービス申込時に提供される「SMF SDK」に含まれるAPIライブラリ等を用いて構築することができます。 APIライブラリでは、RSとして実行可能な機能が実装されており、これをコマンドラインツールやWebインタフェース、 XML-RPCといった外部インタフェースから呼び出すことによって自由にカスタマイズしたサービスを提供することが可能となっています。 なお、APIライブラリはJava API(JDK1.5)の形式で提供されています。
上図は、RSの構築例を模式的にあらわしたものです。 RSで管理・保持されるデータは、すべてデータベースを用いて保存されています。 APIライブラリは、これらをデータモデルとして定義するとともに、Webアプリケーションからの呼び出しを 考慮した検索やリスト表示などの各種メソッドも提供しています。
APIを利用するアプリケーションとしては、一般的なWebアプリケーションとしてTomcatなどのServlet Container上で実装したり、 一般的なコマンドラインツールを作成して管理者用のインタフェースとする、など目的に応じて自由に作りこむことができます。
また、RSと連携して動作する ARMS Proxy Server、Heartbeat ServerはXML-RPC経由でAPIライブラリとの通信を行います。 実際のハンドラクラスはAPIライブラリで提供されていますが、XML-RPCサーバは別途用意し、APIライブラリのハンドラを登録する必要があります。
RSは以下に示す複数の機能が連携して動作しています。
- Resource Manager
RSは、個々のSAの詳細設定を保持しています。SAから設定探索リクエストを受け付けると、RSは適切な設定情報をSAに配布します。 この際、SAは識別子として自身に割当てられたDistribution IDを含めて設定探索リクエストを送信します。 RSはDistribution IDを基に設定情報をデータベースから検索します。
- Remote Operation Manager
SAに対するネットワーク経由での遠隔操作を行います。この遠隔操作はSSL等の安全なプロトコル上で行われます。 また、RSからの制御が失われずに確実に操作が行われるよう想定されています。遠隔操作の内容は、設定変更、SAの再起動、 SAのソフトウェアモジュールのアップデートなどが含まれます。 また、必要に応じてRemote Operation Managerにスケジュール機能を持たせることも可能です。 これにより、あらかじめ設定だけを行っておき、設定の反映は深夜など、ネットワークの利用者が少ない時間に自動的に行うことができます。
- Monitoring Manager
SAの死活監視を行います。これは、連携して動作するHeartbeatサーバからの監視イベントに基づいて動作します。 Heartbeatサーバからは、SAのUP/DOWNが通知され、その結果はRSに保持されます。 UP/DOWNのイベントに基づいてメールを送信する、といったアクションを定義することも可能です。 また、Heartbeatサーバ以外の既存の監視システムと連携を行うことも可能です。
- フロントエンドUI
RSに対する各種操作(設定変更、オペレーション指示等)を行うためのフロントエンドUIを提供します。 UIの提供形態は一般的なWebUIや、XML-RPCインターフェイスで提供することができます。 なお、フロントエンドUIについてはSMF SDKで提供されるRS-APIライブラリを用いてRSベンダが独自に実装を行うことができます。
ARMS-Proxy Server仕様¶
ARMS Proxyサーバは、SAとRSの間で行われる通信を中継するためのサーバです。 RSは、SAと通信するためのARMSプロトコルのインターフェイスは持っておらず、すべてARMS Proxyサーバを経由して通信を行うことになります 1 。
これにより、RS上で提供される各種インターフェイスを広域ネットワーク上から隠蔽することができるほか、 SAからの大量のリクエストなどによる負荷上昇などを防ぐことができます。
ARMS Proxyサーバの動作モデルを以下の図に示します。
SAとARMS Proxyサーバ間の通信はARMSプロトコルを用いて行われます。 用意されるインターフェイスはPullリクエスト(設定探索等)を処理するためのインターフェイスと、 Pushリクエスト(Operation)を処理するためのインターフェイスの2つです。 RSとの通信はXML-RPC経由で行われます。Pullリクエストを受信すると、RSに対してリクエストを中継し、取得した結果をSAに返します。 RSからのOperationリクエストを受信すると、それをいったんProxy内部のデータベースにキューイングした後、 SAに対してARMSプロトコルを用いて安全な手段で実行します。 実行結果も同様にProxy内部のデータベースに保持しておき、RSからの結果取得リクエストに応じて値を返します。 このようにRSのPushリクエストとは非同期で動作することから、RS側でPushの結果を待ち続ける必要がなくなります。
また、ARMS Proxyサーバは簡易的なHTTPプロキシの機能も提供します。 これはARMS Proxyに対するARMSプロトコル以外のHTTPS通信を、他のHTTPサーバに転送する機能です。 SA からインターネットへのアクセスが厳しく制限されARMS Proxy サーバにしかアクセスできないような環境でも、 HTTP 転送機能を介して HTTP サーバにアクセスし、Add-On モジュールをダウンロードすることができます。
- 1
機能としては別になりますが、RSとARMS Proxyサーバを同一のサーバマシン上で構築して並列して動作させることは可能です
Heartbeat Server仕様¶
Heartbeatサーバ¶
RSベンダによって構築されるHeartbeatサーバは、管理下にある全てのSAからのHeartbeatパケットを受信し、記録します。 Heartbeatサーバは過去のHeartbeatパケット受信記録に基づき、定期的に接続状況に変化があったかどうかを検査しています。
具体的には、以下のような状態遷移で接続状況の変化を検出します。
- 初めてHeartbeatパケットを受信した場合
→初期状態がDOWNなので、UPと判断します
- 過去連続してHeartbeatを受信している状況から、3回連続して受信しなかった
→DOWNと検出します(具体的な回数は変更可能です)
- 過去受信していなかった状態(DOWN状態)から、1回Heartbeatを受信した
→UPと検出します(具体的な回数は変更可能です)
Heartbeatサーバは、上記のように状態の変化を検出すると、その結果をRSに対して通知します。この通知はXML-RPC通信を用いて行われます。 通知結果はRSで保持するステータスの値としてセットされ参照可能となるほか、イベントログとしても記録されます。 さらに、あらかじめ登録された通知先に対してメールを送信するといったアクションを定義することもできます。
なお、このHeartbeatを用いた監視の仕組みでは、上記のように
「IPv4またはIPv6でSAとHeartbeatサーバ間の通信が確立していること」
を「UP状態である」と判断することに注意してください。
Heartbeatパケットを用いたグラフ提供機能¶
Heartbeatパケットにオプションパラメータであるトラヒック情報やCPU利用率といった情報が含まれていた場合、 Heartbeatサーバはこれを利用してグラフ情報を提供することができます。
HeartbeatサーバにはWebサーバが含まれており、ここでグラフを表示するためのCGIインターフェイスが含まれています。 このグラフ提供機能の特徴は以下の通りです。
- HTML形式、イメージ形式を選択可能
グラフ表示の際、完全なWebページ形式で表示することができるほか、グラフイメージのみを取得することもできます。 表示するWebUIのスタイルに合わせて自由に選択することができます。
Heartbeat receiver¶
Heartbeatサーバは、SAからのHeartbeatパケットを受信して死活判定を行う機能を提供するサーバです。 RSとして連携して動作するため、RS事業者が構築・運用を行う必要があります。
Heartbeatパケットは、SAの死活判定の他、ステータス情報などの動作情報も含むことができるパケットとして、SMFv2システムで独自に定義されたものです。 SAがこの定義にしたがってHeartbeat送信機能が実装されている場合、Heartbeatサーバでこれを受信して、動作状況を監視することが可能です。
動作状況の変化は必要に応じてRSに自動的に通知され、特定のメールアドレスに対してメールを送信する、といった処理を行わせることが可能です。
また、Heartbeatパケットにステータス情報が含まれていた場合、その情報を元にグラフ化して表示を行うことが可能です。
