応用システム構成¶
SMF SDK では、管理対象となるサービスアダプタが大量に存在する場合のシステムとしての性能向上や、 耐障害性の向上のためにサーバ群を分散化/冗長化させて運用することができます。 本章では、それらのより高度な運用を行うためのサーバ構成のポイントや冗長化方法の詳細について解説します。
システム概要¶
収容分散構成¶
SMF SDK ではサービスアダプタを収容するサーバ群をユーザごと (RS-API での SmfUser に相当します) に分けることにより、 一つの RS システムあたりのサービスアダプタ収容台数の上限を引き上げることができます。
収容するサーバ群は ARMS-Proxy サーバ、Heartbeat サーバ、RS をまとめて「サーバグループ」と呼び、 ユーザのの情報と関連付けられて DB に保存されます。特定のユーザ及びその配下のサービスアダプタは全て、 一つのサーバグループにのみ所属し、どのサーバグループに所属するかは登録時の「デフォルトサーバグループ」によって決定されます。
なお RS は全てのデータを DB に保存し、データを持たないため複数のサーバグループに所属することができます。
RS システム内でサーバグループを複数構成構築した場合でも、収容する DB はただ 1 つです。 このため、DB がボトルネックとなった場合は、複数の RS システムに分離する必要があります。 つまり RSシステムと DB は 1 対 1 の対応となります。
冗長構成¶
サーバグループには複数の ARMS-Proxy サーバまたは Heartbeat サーバを所属させることができ、 これにより同一サーバグループ内に閉じた形での ARMS-Proxy サーバ、または Heartbeat サーバの冗長性を確保します。 サーバグループをまたいでの冗長性の確保はできません。
- 冗長構成時の注意点
冗長構成時に各ホストの時刻が同期していないと正常にシステムが動作しません。 そのため NTP 等を用いて必ず時刻が合うようにホストの設定をしてください。
システム構成例¶
- 2台のサーバホストによる冗長構成
ある程度の耐障害性を持たせた構成となります。
- RSとDBMSを外部ネットワークから隠蔽した構成
SMF SDKのコンポーネントのうち、インターネットと直接接続する必要があるコンポーネントはARMS-ProxyサーバとHeartbeatサーバのみです。 残りのRSとDBMSをインターネットに直接接続しないことで、セキュリティを向上させることができます。
収容分散構成の詳細¶
本節ではサービスアダプタを収容するサーバを分散させる際のポイントを解説します。
サービスアダプタの収容するサーバグループの決定方法¶
新規登録されるユーザは、登録時のデフォルトサーバグループに収容され、 そのユーザに対して登録されるサービスアダプタは、そのサーバグループと結びつきます。
サーバグループの追加タイミングについて¶
サーバグループ内のいずれかのホストが性能上の上限に達する前にサーバグループを随時追加し、デフォルトサーバグループを追加したものに変更します。
また、前述の通り、既存のユーザに対して新規登録されるサービスアダプタも既存のサーバグループに結びつくため、 既存のユーザの将来の増分を考慮に入れた上でサーバグループを追加する必要があります。
Location-Config の設定¶
サーバグループを追加した場合、管理上 Location-Config は別の RS として LS に登録してください。
冗長化方法の詳細¶
本節では冗長構成の動作概要、必要な設定、制約等を各連携ポイントごとに解説します。
サービスアダプタ/ARMS-Proxy サーバ¶
動作概要
- サービスアダプタ起動時 (PULL) の冗長性
サービスアダプタは起動時に LS システム、または RS システムから渡されたサーバグループ内の複数の URL に対して順次アクセスを試みるため冗長性が確保されています。
初期状態のサービスアダプタの ARMS-Proxy サーバへのアクセス順序は、各設定に書かれた順番と同一です。 ただしサービスアダプタが前回の接続情報をキャッシュとして持っている場合は、前回の起動時に接続できた ARMS-Proxy サーバの試行順序を前に回してアクセスします。 サービスアダプタが持続型接続で起動した場合は、サーバグループ内の全ての ARMS-Proxy サーバに対して SSL トンネルを張った状態を維持します。 この SSL トンネルはトンネル接続確認用のパケットが定期的に流れており、サービスアダプタがトンネルの切断を検知すると、そのトンネルの再接続をサービスアダプタが自動的に試みます。
全ての ARMS-Proxy と通信ができなかった場合、または持続型接続で全てのトンネルが切断された場合サービスアダプタは SMF 起動シーケンスをやり直します。
- サービスアダプタへの操作時 (Push) の冗長性
一度 ARMS-Proxy サーバに RS から引き渡された操作要求は冗長化されません。 そのため、実行中にホスト OS が再起動された場合、要求は喪失します。
ただし、ARMS-Proxy サーバに引き渡される前の操作要求は同一サーバグループの ARMS-Proxyサーバに対して RS が順次要求を伝えようと試みるため実行前の操作要求は冗長化されます。
この引き渡し時の試行は DB に登録された ARMS-Proxy サーバの順序を基本とし、操作接続の接続性確認が済んでいる ARMS-Proxy サーバが優先されます。
また、スケジュール実行による Push 操作も各 ARMS-Proxy サーバから定期的に取得し、冗長化が行われます。
冗長化に必要な設定
LS での複数 Location-Config の設定
RS での複数 ARMS-Proxy サーバ登録
Proxy での操作要求の実行結果の保存先を RS に設定し、RS/DBMS を冗長化
- 冗長化に関する制約
なし
サービスアダプタ/Heartbeat サーバ¶
動作概要
- Heartbeat パケットの冗長性
サービスアダプタは同一の内容の Heartbeat パケットを RS システムから渡されたサーバグループ内の複数のアドレスに対して順次送信するためデータの冗長性が確保されています。 複数の Heartbeat サーバに届いた Heartbeat パケットのデータはそれぞれのローカルファイルシステム上に保存され、Heartbeat サーバ間で監視およびグラフ用データの同期は行われません。
冗長化に必要な設定
RS での複数 Heartbeat サーバ登録
冗長化に関する制約
障害からの復旧時に正常系の Heartbeat サーバからオンラインでデータを複製することはできません
ARMS-Proxy サーバ/RS¶
動作概要
- ARMS-Proxy サーバから RS へのアクセス
ARMS-Proxy サーバは proxy.cfg に書かれた複数の RS の URL に対して順次、アクセスを試みるため冗長性が確保されています。 また、接続確認が取れなかった RS の URL は一定時間保持され、その URL へのアクセスは飛ばされます。
- RS から ARMS-Proxy サーバへのアクセス
RS は DB に登録されたサーバグループ内の複数の ARMS-Proxy サーバの URL に対して順次アクセスを試みるため冗長性が確保されています。
この方向のアクセスはサービスアダプタへの操作時およびその結果の内容の取得時にのみ発生します。 アクセスの順序は登録された ARMS-Proxy サーバの順序を基本とし、その上で操作接続の接続性確認が済んでいる ARMS-Proxy サーバが優先されます。
また、接続が取れなかった ARMS-Proxy サーバの URL は一定時間保持され、その URL へのアクセスは飛ばされます。
冗長化に必要な設定
ARMS-Proxy サーバの proxy.cfg での複数 rs-rpc-url の記述
RS での複数 ARMS-Proxy サーバ登録
Proxy での操作要求の実行結果の保存先を RS に設定し、RS/DBMS を冗長化
冗長化に関する制約
実行中の操作は冗長化されません
Heartbeat サーバ/RS¶
動作概要
- 監視結果通知の冗長性
RS に対する UP/DOWN の監視結果の通知はサーバグループ内で 1 つの Heartbeat サーバでのみ有効化する必要があります。 このためアクティブ・スタンバイ構成となり、障害時は手動でHeartbeat サーバの cron 設定を追加・削除し Heartbeat サーバのスタンバイ系とアクティブ系を入れ替える必要があります。
また RS へのアクセスは hbserver.conf に書かれた複数の RS の URL に対して順次、アクセスを試みるため RS の障害については冗長性が確保されています。
冗長化に必要な設定
Heartbeat サーバの hbserver.conf での複数 RSURL の記述
RS での複数 Heartbeat サーバ登録
- cron の登録
アクティブ系
#/etc/cron.d/hbserver */5 * * * * heartbeat /var/service/smf/bin/mreport.pyスタンバイ系
#/etc/cron.d/hbserver */5 * * * * heartbeat /var/service/smf/bin/mreport.py -s
冗長化に関する制約
監視結果の通知は Heartbeat サーバ側での障害があった場合には冗長化されません
RS/DBMS¶
SMF SDK がサポートする MySQL InnoDB は Master/Slave 構成のレプリケーションが取れるため、データの冗長化が可能です。 設定方法については MySQL 付属のドキュメントをご覧ください。ただし、自動フェイルオーバーは MySQL InnoDB ではサポートされていないため、 RS での DBMS アクセス先を変える等の作業を行い、手動で切り倒す必要があります。
Web ブラウザ/RS¶
一般的なロードバランサの HTTP 監視機能やアプリケーションコンテナを利用した場合、それらの機能を利用し冗長化が可能な場合があります。 詳細については各ソフトウェアのドキュメントをご覧下さい。
Web ブラウザ/Heartbeat グラフ CGI¶
一般的なロードバランサの HTTP 監視機能や Apache 2.2.x の mod proxy で Heartbeat グラフCGI(httpd) の生死のみの判定による冗長化が可能です。
切り倒し/切り戻し方法¶
本節では、冗長化された RS システムにおいてサーバ障害時またはホスト OS やライブラリ、 RS-UIのアップデート時に手動で切り倒す方法およびサーバメンテナンスからの復旧時に切り戻す方法を説明します。
ARMS-Proxy サーバ切り倒し方法¶
ARMS-Proxy サーバを停止してください。
# /sbin/service arms-proxy stop
ARMS-Proxy サーバ切り戻し方法¶
ARMS-Proxy サーバを起動してください。
# /sbin/service arms-proxy start
Heartbeat サーバ切り倒し方法¶
- アクティブ系の cron の停止
以下の行をコメントアウトして cron のスケジュールを停止します。
# vi /etc/cron.d/hbserver #*/5 * * * * heartbeat /var/service/smf/bin/mreport.py
アクティブ系の hbserver の停止
# /sbin/service hbserver stop
- スタンバイ系の cron の修正
スタンバイ系専用動作モードからアクティブ系専用モードに cron のスケジュールを変更します。
# vi /etc/cron.d/hbserver */5 * * * * heartbeat /var/service/smf/bin/mreport.py
Heartbeat サーバ切り戻し方法¶
- スタンバイ系の cron の修正
アクティブ系専用動作モードからスタンバイ系専用モードに cron のスケジュールを変更します。
# vi /etc/cron.d/hbserver */5 * * * * heartbeat /var/service/smf/bin/mreport.py -s
アクティブ系 hbserver の開始
# /sbin/service hbserver start
- アクティブ系 cron の開始(スタンバイ系専用モード)
コメントアウトした cron のスケジュールを戻します。 ただし、監視状態の同期のため、hbserver が起動してからしばらくの間スタンバイ系専用モードで cron を再開します。 スタンバイ系専用モードで動作が必要な時間は、hbserver.conf の設定により異なりますが、デフォルトでは 20 分となります。
# vi /etc/cron.d/hbserver */5 * * * * heartbeat /var/service/smf/bin/mreport.py -s
- アクティブ系 cron の修正
スタンバイ系専用動作モードからアクティブ系専用モードに cron のスケジュールを変更します。
# vi /etc/cron.d/hbserver */5 * * * * heartbeat /var/service/smf/bin/mreport.py
RS 切り倒し方法¶
UI からの操作を遮断後、アプリケーションコンテナを停止してください。 ARMS-Proxy サーバとHeartbeat サーバは自動的に動作中の RS へフォールバックし始めます。
RS 切り戻し方法¶
アプリケーションコンテナを起動してください。 一定時間後 ARMS-Proxy サーバと Heartbeat サーバは起動してきた RS へアクセスし始めます。
