Hinemosミッションクリティカル機能アーキテクチャとその信頼性

© 2017 NTT DATA INTELLILINK Corporation
Hinemosミッションクリティカル機能アーキテクチャと
その信頼性
NTTデータ先端技術株式会社佐野譲
Hinemos World 2017

2© 2017 NTT DATA INTELLILINK Corporation
・はじめに
・アーキテクチャ概要
・QA形式での詳細解説
- syslogおよびsnmptrapの転送
- フェイルオーバ
- 障害復旧
・まとめ
目次

© 2017 NTT DATA INTELLILINK Corporation 3
はじめに

Hinemos ver.6.0のミッションクリティカル機能について、
Hinemosの独自アーキテクチャによるクラスタの仕組みを解
説。
他クラスタミドルの導入や共有ディスクを必要とせず、
Hinemos自身により実現するヘルスチェック、フェイルオー
バの具体的な仕組みの解説を通して、ユーザ操作の容易性と
信頼性の高いミッションクリティカル機能について習熟いた
だけるセッション。
はじめに

アーキテクチャ概要

Hinemos ミッショ
ンクリティカル機能
クラスタリングソフト仮想化・クラウド
(サーバ自動リブート)
ハードウェア障害 ○ ○ ○
OS障害 ○ ○ ○
ソフトウェア障害 ○
△
(環境に依存)
✕
障害検出時間
○
(1～2分程度)
△
(環境に依存)
✕
(数分～数10分)
ポーリング型監視
の継続性
PING/リソース/プロセス監視など
○ ○ ○
トラップ型監視の
継続性
syslog/SNMPTRAPなど
○
(サーバ切替中の
syslog/SNMPTRAPを
監視可能）
△
syslog/snmptrapは
監視不可)
△
syslog/snmptrapは
監視不可)
ジョブの継続性
○
(検証済み)
△
(未検証)
△
(未検証)
導入容易性 ○
✕
(設計および検証が必要)
○
運用容易性 ○
✕
(独自の手順書が必要)
○
ミッションクリティカル機能の比較

ミッションクリティカル機能の構成 (Hinemos独自アーキテクチャ)
Server #1
Cluster Controller (JavaVM)
Server #2
Management-Plane
SIP SIP
FIP
PostgreSQL (Master)
Hinemos Manager
(JavaVM)
Cluster Manager (powered by JGroups)
Health Check Monitor
同期レプリケーション
Resource Manager
PostgreSQL (Standby)
Hinemos Manager
(JavaVM)
Resource Manager
サーバヘルスチェック
rsyslog
Syslog/Snmptrap Buffer Syslog/Snmptrap Buffer
rsyslog
UDP UDP
TCP(HTTP)
UDP UDP

FIP(Floating IP address)
Server #1
Server #2
Management-Plane
SIP SIP
FIP
PostgreSQL (Master)
Hinemos Manager
(JavaVM)
Resource Manager
Hinemos Manager
(JavaVM)
Resource Manager
rsyslog
rsyslog
UDP UDP
TCP(HTTP)
Hinemosクライアント導入システム
or
監視対象システム
UDP UDPMasterサーバへアクセスするための仮想IPアドレス。
（利用用途）
・HinemosクライアントからHinemosマネージャへの接続先
・HinemosエージェントからHinemosマネージャへの接続先
・syslog/snmptrapの送信先が複数設定できない機器からの
Hinemosマネージャサーバへの接続先

SIP(Static IP address)
Server #1
Server #2
Management-Plane
SIP SIP
FIP
PostgreSQL (Master)
Hinemos Manager
(JavaVM)
Resource Manager
Hinemos Manager
(JavaVM)
Resource Manager
rsyslog
rsyslog
UDP UDP
TCP(HTTP)
UDP UDP
各サーバへアクセスするための物理IPアドレス。
（利用用途）
・syslog/snmptrapの送信先が複数設定できる機器からの
Hinemosマネージャサーバへの接続先（ロスレス）
※フェイルオーバ中はFIPは一時的アクセスできなくなるた
め。

Syslog/Snmptrap Bufferの仕組み
Server #1
Server #2
Management-Plane
SIP SIP
FIP
PostgreSQL (Master)
Hinemos Manager
(JavaVM)
Resource Manager
Hinemos Manager
(JavaVM)
Resource Manager
rsyslog
rsyslog
UDP UDP
TCP(HTTP)
受信したsyslogおよびsnmptrapをHinemos
Manager(JavaVM)へロスレスで転送する機構。
（処理内容）
・syslogおよびsnmptrapの受信処理
・syslogおよびsnmptrapの重複チェック
・Hinemos Manager(JavaVM)への送信
（共有キャッシュ）
直近に処理したsyslogおよびsnmptrapの
履歴情報を両系サーバで共有し、
重複チェックの判定に用いる。
共有キャッシュ
後程説明
UDP UDP

Resource Managerのリソースを管理の仕組み
Server #1
Server #2
Management-Plane
SIP SIP
FIP
PostgreSQL (Master)
Hinemos Manager
(JavaVM)
Resource Manager
Hinemos Manager
(JavaVM)
Resource Manager
rsyslog
rsyslog
UDP UDP
TCP(HTTP)
クラスタ上で制御されるリソースの起動を管理する機構。
（処理内容）
・MasterサーバにてFIPを付与
・MasterサーバにてHInemos Manager(JavaVM)を起動
・MasterサーバにてPostgreSQLを同期レプリケーション
モードで起動
・StandbyサーバにてPostgreSQLをrecoveryモードで起動
・制御失敗時、Cluster Managerへ通知して系切替
UDP UDP

Health Check Monitorの状態監視の仕組み
Server #1
Server #2
Management-Plane
SIP SIP
FIP
PostgreSQL (Master)
Hinemos Manager
(JavaVM)
Resource Manager
Hinemos Manager
(JavaVM)
Resource Manager
rsyslog
rsyslog
UDP UDP
TCP(HTTP)
各サーバの死活監視をする機構。
（処理内容）
・ファイルシステムのヘルスチェック(Read/Write ⇒
作成、書き込み、読み込み、削除)
・外部ネットワークからのサーバ孤立の検知(ping)
・ネットワークインタフェースのヘルスチェック(ping)
FIPのヘルスチェック(ping)(Master)
・PostgreSQLのヘルスチェック(pg_isready)
・Hinemos Manager (Java VM) のヘルスチェック
(wget)
・障害判定時、Cluster Managerへ通知して系切替
後程説明
UDP UDP

Cluster Managerによるクラスタを構成する各サーバ間の状態管理の仕組
み
Server #1
Server #2
Management-Plane
SIP SIP
FIP
PostgreSQL (Master)
Hinemos Manager
(JavaVM)
Resource Manager
Hinemos Manager
(JavaVM)
Resource Manager
rsyslog
rsyslog
UDP UDP
TCP(HTTP)
クラスタを構成する各サーバ間の状態管理。
（処理内容）
・クラスタ構成管理（Master/Standby)
・ハートビート通信およびステートフルセッションに
よる相対サーバのヘルスチェック
・障害判定時、系切替（スプリットブレイン防止機構
あり）
後程説明
UDP UDP

QA形式での詳細解説
syslogおよびsnmptrapの転送

syslog転送において、重複判定で突合されない情報を以下から一つ選択せよ。
① facility/severity部
② 送信元IPアドレス
③ timestamp部
④ program name部
【解答】 ②
参考) Hinemos HAオプション ver6.0 ユーザマニュアル - 3.3.1 syslogおよびsnmptrapの転送アーキテクチャ
syslog転送

snmptrap転送において、重複判定で突合されない情報(v1)を以下から一つ選択
せよ。
① Agent Address
② Enterprise ID
③ Time Stamp
④ Variable Bindings
【解答】 ③
syslogと比べて精度が細
かいため、TimeStamp
は突合対象から除外して
いる。
参考) Hinemos HAオプション ver6.0 ユーザマニュアル - 3.3.1 syslogおよびsnmptrapの転送アーキテクチャ
snmptrap転送

【解答】 ①
参考) Hinemos HAオプション ver6.0 ユーザマニュアル - 9.3 syslog/snmptrap転送に関する設定
syslog/snmptrap転送
syslog/snmptrap転送において、重複判定の突合に用いられるメッセージ履歴
の生存期間[sec]を一つ選択せよ。
① 30
② 60
③ 90
④ 120

1, 2号機のシステム時刻がずれている場合、 syslog/snmptrap転送で生じうる
障害を以下から一つ選択せよ。
① 重複判定が正常に機能せず、転送されない
② 重複判定が正常に機能せず、重複されて転送される
③ 転送処理が正常に機能せず、転送されない
④ 何も障害は発生しない
参考) Hinemos HAオプション ver6.0 ユーザマニュアル - 9.3 syslog/snmptrap転送に関する設定
【解答】 ②
履歴情報の保持期間が30[sec]であるこ
とがポイント。システム時刻がずれて
いると、履歴情報が正しく保持されず、
本来重複として判定されるべきメッ
セージが新規と判定されてしまう。
syslog/snmptrap転送

フェイルオーバ

ファイルシステムのヘルスチェックの動作として不適切なものを一つ選択せよ。
① /opt/hinemos/.rw_checkに対して、生成・書き込み・読み込み・削除を
実行している
② smartdによるディスクアクセスエラー数をチェックしている
③ 生成・書き込み・読み込み・削除の一連の処理が4.5秒以上の時間を要し
た場合に異常と判定
④ 片系運転にて障害と判定された場合、そのサーバ上のCluster Controller
は停止しない
【解答】 ②
RAID構成などで正しく取得できない可能性のあるsmartdの値は参照してない。
④は、片系運転の場合になるべく同等の動作とすることを目的としている。
参考) Hinemos HAオプション ver6.0 ユーザマニュアル - 9.2 クラスタ制御に関する設定
ファイルシステムのヘルスチェック

hinemos_ha_configure.shの「External IP Addresses used by Health
Check」にて指定されたIPアドレスのリストに対して、定期的にpingコマンドに
よるヘルスチェックを行っている。そのヘルスチェックの動作として不適切なも
のを一つ選択せよ。
① いずれかのIPアドレスに疎通できなくなった場合、異常と判定する
② 監視間隔は5秒間隔
③ 障害判定は異常が６回連続の場合
④ 障害と判定された場合、そのサーバ上のCluster Controllerは停止する
【解答】 ①
すべてのIPアドレスに疎通ができな
くなった場合、異常と判定。
一部の機器がメンテナンス停止され
ても切り替わらないように。
④の動作に注意。外部NWからの遮
断 → 片系運転と”勘違い”の可能性
あり → SplitBrainを避けるため、
Cluster Controllerは停止
外部ネットワークからのサーバ孤立検知

相対サーバのヘルスチェックとして、Cluster Controllerはお互いに相手の状態
をチェックする。そのヘルスチェックの動作として不適切なものを一つ選択せよ。
① tcp:27800に対して定期的にハートビートパケットを送信
② ハートビートパケットの送信は3秒間隔
③ 60秒以上ハートビートパケットを受信できなかった場合に異常と判定
④ ステートフルセッション(tcp:27900)が相対サーバからcloseされた場合
に異常と判定
【解答】 ③
30秒以上ハートビートパケットを受信できなかった場合に異常と判定される。
ハートビート通信およびステートフルセッションによる相対サーバ
のヘルスチェック

第1(SSH)および第2(IPMI)のスプリットブレイン防止機構の動作について不適
切なものを一つ選択せよ。
① SSHでログインし、相手のサーバ上のプロセス・FIPを停止する
② SSH実行前に相手サーバのping応答が無かった場合、何もしない
③ 第1の機構が失敗したのみしか、第2の機構は発動しない
④ IPMIコマンドの正常終了により、第2の機構を成功と判定する
【解答】 ④
IPMIコマンドの戻り値は確認しない。
IPMIコマンドの発行後、ping応答が無くなるまで待機し、第2の機構を成功と
判定する。
・スプリットブレイン防止機構とは
障害判定時、Standbyサーバが新Masterサーバに昇格する前に、
元Masterサーバの強制停止を試みる機構。
両系サーバがMasterとして起動されてしまうこと(スプリットブレイン)を
防ぐ機構である。参考) Hinemos HAオプション ver6.0 ユーザマニュアル -
4.1.7 スプリットブレイン防止機構(IPMI経由)を利用する場合(オンプレミス環境)
スプリットブレイン防止機構

障害復旧

可用性構成への復旧方法として最も適切なものを一つ選べ。
① Cluster Controllerが停止しているサーバでhinemos_ha_start.shだけを
実行する
② Cluster Controllerが停止しているサーバでpg_sync.shを実行した後、
hinemos_ha_start.shを実行する
③ Cluster Controllerが起動しているサーバでpg_sync.shを実行した後、
Cluster Controllerが停止しているサーバでhinemos_ha_start.shを実行
する
④ PostgreSQL、Hinemos Managerの順で手動で起動する
【解答】 ①
いずれの障害ケースであっても、切り離されたサーバをOSが正常に動作する状
態に復旧し、hinemos_ha_start.shを実行するだけでよい。
参考) Hinemos HAオプション ver6.0 ユーザマニュアル - 7.1.3 復旧方法
障害で停止したサーバの復旧方法

オペレーションミスあるいは両サーバ上のプロセス暴走による強制停止により、
両サーバがStandby状態で停止された状態となる可能性がある。その場合、どち
らのサーバも.pg_lockファイルが存在するため、ロックファイルを無視する-F
オプションで起動するサーバの選定方法として最も適切なものを一つ選択せよ。
① どちらのサーバでも構わない
② 両系のcluster_status.logを参照し、最後までPostgreSQLがMaster状態
で動作していたサーバで実行する
③ 両系のpostgresql.logを参照し、最後までPostgreSQLが動作していた
サーバで実行する
④ 両系のhinemos_manager.logを参照し、最後までHinemos Managerが
動作していたサーバで実行する
【解答】 ②
最後までMasterとして動作していたPostgreSQLに、最新の履歴データが格納
されている。そのため、データ消失が無いよう、適切なサーバをMasterとして
再起動すべき。
参考) Hinemos HAオプション ver6.0 ユーザマニュアル
- 5.1.3 いずれのサーバもMasterサーバとして起動できない場合
両サーバにて起動しなくなった場合の対処法

まとめ

まとめ
Hinemos ver.6.0のミッションクリティカル機能について、
Hinemosの独自アーキテクチャによるクラスタの仕組みを解
説。
・Hinemosの可用性確保に特化した独自アーキテクチャ
であること
・簡単な復旧操作により複雑な運用手順書が不要である
こと
上記ご理解いただき、是非導入をご検討ください。

Hinemosミッションクリティカル機能アーキテクチャとその信頼性

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Hinemosミッションクリティカル機能アーキテクチャとその信頼性

Similar a Hinemosミッションクリティカル機能アーキテクチャとその信頼性 (20)

Más de Hinemos

Más de Hinemos (20)

Último

Último (11)

Hinemosミッションクリティカル機能アーキテクチャとその信頼性