基本システム構成¶
本章では、サーバの各コンポーネント上で動作する各種プロセスの動作と役割、また基本的な運用手順や設定項目の概要について解説します。
システム概要¶
本節では、 RS システム (SMF SDK を用いて構築した SMFv2 サーバシステム) 内の各コンポーネントの概要と、それらの連携動作について説明します。
ARMS-Proxy サーバ
Heartbeat サーバ
RS
全てのコンポーネントを一つのホスト OS 内にインストールする、もっとも基本的な構成は下図のようになります。
この構成は、RS システムを動作させることができる、もっともシンプルな構成です。 可用性やスケーラビリティはもっとも低くなりますが、開発や基本動作の検証用途にはこの構成が適しています。
ARMS-Proxy サーバ¶
- 主な構成パッケージ
arms-proxy-*.rpm
- arms-proxy (/var/service/smf/bin/proxy-start.py)
サービスアダプタと RS 間の Heartbeat パケット以外の全ての SMF に関する通信を仲介するデーモンプロセスです。 サービスアダプタからの SSL 通信を終端し、RS に情報を引き渡します。 また、RS からの指示によりサービスアダプタへの SSL 通信 (Push) を行います。
RS からの要求によってサービスアダプタから取得したデータをファイルシステム上に保存し、 設定 (proxy.cfg:push-result-save-to) に従って RS へ通知します。 また、結果取得の成否および自身のアドレス (proxy.cfg:my-rpc-url) も同時に RS へ通知します。 サービスアダプタからの要求はファイルシステムへは保存されません。
TCP 通信元
サービスアダプタ, RS-API
TCP 通信先
サービスアダプタ, RS-API
- proxy-show-status.py (/var/service/smf/bin/proxy-show-status.py)
ARMS-Proxy サーバの状態を取得するプログラムです。 実行結果を JSON オブジェクトとして標準出力に出力します。
それぞれの値の意味は次のようになります。
名前
意味
https_tunnel_connections
接続中の https-tunnel 数
https_tunnel_connections_limit
https-tunnel 数の上限 (設定値)
push_free_workers
同時に Push できる上限 (実行時点)
push_workers
同時に Push できる上限 (設定値)
push_remain_tasks
未処理の Push タスク数
push_running_sa
操作中の SA (Distribution ID) のリスト
date
実行日時
Heartbeat サーバ¶
- 主な構成パッケージ
heartbeat-server-*.rpm
- hbserver (/var/service/smf/bin/hbserver)
サービスアダプタから独自 UDP プロトコルにより送られたパケット (Heartbeat パケット) を受け取り、 その時刻とパケット内に含まれるグラフ用のデータを定期的にファイルシステム上に書き出すデーモンプロセスです。
サービスアダプタは RS から指示された IP アドレス、ポート番号、共有秘密鍵、送信間隔といった情報を元に Heartbeat パケットを送信するため、RS と hbserver との間で設定が揃っている必要があります。
UDP 通信元
サービスアダプタ
- mreport.py (/var/service/smf/bin/mreport.py)
hbserver がファイルシステム上に書き出した時刻を元に、Heartbeat パケットの到達状況を解析し、 必要に応じて RS に対して UP/DOWN を通知する cron スクリプトです。
設定した監視間隔ごとに cron によって実行される必要があります。
このスクリプトにより判定対象となるサービスアダプタの一覧が RS より取得され、その後、判定結果を RS へ通知します。
TCP 通信先
RS-API
- grapher.cgi (/var/service/smf/cgi/hb/grapher.cgi)
hbserver がファイルシステム上に書き出したグラフ用データを元に、画像または HTML を生成する CGI スクリプトです。
アクセスごとにグラフの生成を行うことを避けるため、ファイルシステム上に画像キャッシュを作成します。
TCP 通信元
ブラウザ等 (UI 依存)
RS¶
- 主な構成パッケージ
rs-api-*.jar
ユーザアプリケーション
- RS-API(java)
RS システムの中核となる Java ライブラリです。UI 用の API を提供し、各コンポーネントとの通信を担当します。 SMF SDK のデータベーステーブルへの全てのアクセスはこのライブラリを通して行われます。 また、このライブラリを利用したユーザアプリケーションがデーモンプロセスとして動作します。
TCP 通信元
arms-proxy, mreport.py
TCP 通信先
arms-proxy, DBMS
- RS-UI(java)
RS-API を使ったアプリケーションです。デモ環境では Tomcat などのアプリケーションコンテナ上で RS-API と共に動作します。 ユーザによる監視通知や UI のカスタマイズ部分はここに含まれます。
通信元
実装依存
通信先
実装依存 (デモ環境では監視通知用の SMTP サーバなど)
停止/起動の順序について¶
メンテナンス等で順次プロセスを停止・起動させなければならない時は、以下の順序で行ってください。 基本的にサービスアダプタに近い cron タスク・デーモンから停止させます。
起動状態からの全停止
mreport.py cron タスクの停止
hbserver, arms-proxy の停止
RS-API, RS-UI の停止
DBMS の停止
停止状態からの全起動
DBMS の起動
RS-API, RS-UI の起動
hbserver, arms-proxy の起動
mreport.py cron タスクの開始
アップデート¶
ベース部分 (SMF SDK) のアップデート¶
「システム移行ガイド」をご覧ください。
カスタマイズ部分 (RS-UI) のアップデート¶
SMF SDK のバージョンアップが伴わず、RS-UI のカスタマイズ部分のみ入れ替える場合、 ARMSProxy サーバ、Heartbeat サーバの停止は必須ではありません。ただし、これらのコンポーネント上のプロセスが RS-API にアクセスできなくなるためエラーログが出てしまうことに注意が必要です。
監視方法¶
各デーモンプロセスの生死状況をリモートから判断する場合、以下のアドレスに対する TCP の接続性を確認することにより監視が可能です。
-ARMS-Proxy サーバ
図
監視対象プロセス
アドレス/ポート
A
arms-proxy
サービスアダプタがアクセスするもの
B
arms-proxy
proxy.cfg の my-rpc-url で指定したもの
Heartbeat サーバ
図
監視対象プロセス
アドレス/ポート
C
hbserver
hbserver.conf の ControlBindAddress および ControlPort で設定したもの
RS
図
監視対象プロセス
アドレス/ポート
D
アプリケーションコンテナ
(java) ポート 80, 8080 等
IPv6 対応¶
IPv4/IPv6 に両対応するための設定について説明します。各コンポーネントで以下のように設定してください。
LS での設定
IPv6 URL の登録
回線タイプ RA の登録
RS でのサーバ設定
IPv6 Proxy の登録。ホスト名はそれぞれ別のものにする
IPv6 Heartbeat の登録。ホスト名は対応する IPv4 のホストと合わせる
Proxy での設定 (proxy.cfg)
セクションを追加し、追加したセクションの ArmsListenAddress に IPv6 アドレスを指定する。 意味/設定例はインストールガイドを参照
Heartbeat サーバでの設定 (hbserver.conf)
HeartbeatBindAddress に any を指定する
IPv6 対応後の動作の変更点は以下のようになります。
SA は Push Method Query に成功したアドレスファミリのみ Push 処理に使用する (RS から取得したコンフィグに依存)
Proxy は IPv4/IPv6 それぞれにプロセスを起動し、Pull/Push 処理を行う
Heartbeat は IPv4/IPv6 両方でダウンの判定になった場合に SA をダウンと判定する。 逆にIPv4/Ipv6 どちらかでもアップ判定になると SA をアップと判定する
