| 毎週発行されているパートナーNewsより選り抜きの記事をご紹介！ |
|
第十八回 『セキュリティポリシー：セキュリティ運用維持』
|
● 稼動監視と障害管理（その2）
|
■ セキュリティポリシー：セキュリティ運用維持
経営基盤の中核となりつつあるITインフラを停止せず、業務遂行のためにシステムを提供し続ける事、もしくは停止時間を最小限に抑える事は情報システム担当部門の責務であると言えましょう。その責務を果たすために、システムの稼動状況の把握と障害発生時にダウンタイムを短縮するといった仕組み作りは、能動的に損失の発生をコントロールする事を意味し、必要不可欠な事前準備と言えます。
稼動監視を進める上で、「何をどのように監視すれば良いのか。」という漠とした問題に直面しますが、システム停止時の影響度とシステムが抱えるデータの価値、両者を勘案した重要度により、稼動監視と障害管理方式を分類する必要があります。
また、稼動監視の前提として、監視対象に何のハードウェアを搭載し、どのネットワーク機器に収容され、障害発生時には、どのような影響をおよぼすのか(例：ハードウェアの交換が必要でダウンタイムが長引く等)を予測するために、監視対象の構成を管理する必要があります。
ここでは、システム/ネットワークの重要度を規定し、その重要度毎に稼動監視方式の定義と、それに伴う障害管理方式を規定することにより、システム利用者が快適に業務をこなせる環境を提供し続けます。
● 障害監視方式
監視システムが提供する障害監視方式を以下に示します。
・ I/F監視(死活監視)
I/F監視(死活監視)は、監視システムから監視対象のLAN I/Fに対し、ステータスポーリング(PING)を実施する事により行われます。ステータスポーリングの応答が無くなると、監視システム内の監視プロセスから、SNMPマネージャへノードダウンのTrapが上がります。このTrapの中には、IP通信障害を起こした、管理対象ノードのホスト名が含まれており、これをもとに、監視サーバに表示します。
監視ツールによってはグラフィカルな表示が可能となります。ツール機能例として、書外発生時にネットワークマップに該当するシンボルの表示色が赤色に変化します。また、障害メッセージの表示と障害通知メールを発信し、障害が発生した記録を残します。
※用語解説
SNMP：Simple Network Management Protocolの略で、TCP/IPプロトコルの一つとして開発された、ネットワーク管理プロトコル。管理システム(マネージャ)とネットワーク機器(エージェント)間で管理に必要なデータを授受する方法を決めている。
・ ログ監視
ログ監視は、監視対象システム上に常駐する監視エージェントが、定期的にログファイルの内容をチェックし、システムの状態を確認すべき文字列(メッセージパターン)が存在した場合は、監視サーバへSNMP Trapを送信し、マップ上の該当シンボルの表示色を変え、メッセージの表示と障害通知メールを発信します。
・ コマンド実行監視
コマンド実行監視は、監視対象システム上に常駐する監視エージェントが、プロセス/ディスク容量/メモリ使用量/CPU使用率といったコマンドを実行します。実行結果から、停止や閾値オーバを判断された場合は、監視サーバへSNMP Trapを送信し、マップ上の該当シンボルの表示色を変え、メッセージの表示と障害通知メールを発信します。
・ MIBの状態監視
ファームウェア/アプリケーション固有で提供するMIBの状態を監視し、特定のMIBの値が変わった場合、監視サーバへSNMP Trapを送信し、マップ上の該当シンボルの表示色を変え、メッセージの表示と障害通知メールを発信します。
※用語解説
MIB：Management Information Baseの略で、ネットワーク管理システムが参照する、管理対象に関するデータベース。管理対象のシステム/製品に関すること、実装や動作状態に関すること、などの情報をオブジェクトとして扱い、それぞれの項目にオブジェクト識別子をつけ階層化ツリー構造にして管理する。
● 検知された障害毎(重要度)の対処方式
検知された障害の対処方式を、システム/ネットワークに分類し、重要度毎に以下に示します。
・ システム
（1）重要度3
リカバリ方式にフォールトトレラントを採用しているため、システムは停止しないが、パフォーマンスは劣化します。早急な復旧作業は必要としませんが、二次障害とパフォーマンス劣化を避けるため、障害発生後は機器の入替えのための作業を行う必要があります。
（２）重要度2
リカバリ方式にホットスタンバイ方式を採用しており、業務の継続は可能ですが、二次障害による業務の停止と、そのリスクを回避するために、主系のハードウェア(障害が発生したハードウェア)の復旧に関わる作業を行う必要があります。
（３）重要度1
リカバリ方式にコールドスタンバイ方式を採用しており、フェイルオーバーが発生します。業務の継続は可能ですが、ホットスタンバイに比べ業務再開には時間を要します。二次障害による業務の停止と、そのリスクを回避するために、主系のハードウェア(障害が発生したハードウェア)の復旧に関わる作業を行う必要があります。
・ 変更管理
物理的に「どのデバイスがどの様に接続されているか」、「アドレスはどうなっているか」を把握し、障害管理、変更管理を行う上での、最低限の情報を提供します｡
（４）重要度0
リカバリ方式は採用していないため、障害発生時は共用代替機を使い復旧を行います。
・ ネットワーク
（1）重要度3/重要度2
リカバリ方式に、HSRP(VRRP)による二重化を採用しているため、業務は停止しないが、二次障害による業務の停止と、そのリスクを回避するために、主系のハードウェア(障害が発生したハードウェア)の復旧に関わる作業を行う必要があります。
※用語解説
HSRP：Hot Standby Routing Protocolの略で、Cisco Systems社製のレイヤ3機器に実装され、多重化を行なうためのプロトコル。各レイヤ3機器に一つずつIPアドレスを振った上で、多重化されているレイヤ3機器全体にさらに1つIPアドレスを割り当て、通信する際は全体用のIPアドレスに要求を送信する。通常の通信に使用されるレイヤ3機器は1つで、使用中のレイヤ3機器が停止すると自動的に別のレイヤ3機器1台が代わって通信を行なう。
※用語解説
VRRP：Virtual Router Redundancy Protocolの略で、ネットワーク機器の多重化を行なうためのプロトコル。VRRPに対応したネットワーク機器を1つのグループに所属させ、通常はそのうち1つのネットワーク機器が通信を行なうが、障害を起こした時に同グループに属するネットワーク機器が自動的に通信を受け継ぐ。
（２）重要度1/重要度0
リカバリのために、代替機を常時用意しており、主系のハードウェア(障害が発生したハードウェア)の復旧に関わる作業を行います。
● 障害報告連絡ルートと命令伝達ルート
障害が発生してから、復旧し通常運用までのプロセスに基づき、障害報告連絡ルートと命令伝達ルートを規程します。基本的には、障害が発生したシステムの担当者/責任者が主体となり復旧に務めるが、障害が発生したシステムを特定するには、複数のシステム担当者/責任者が並行で切り分けるプロセスが発生します。従って、複数のシステム担当者/責任者の作業状況を把握し、判断をする統括責任者が必要となります。
本項では、システム責任者を「M(マネージャ)」と表現し、システム担当者は「正」もしくは「副」と表現します。
・ 障害報告ルート
（1）障害状況調査報告/障害発生の広報
監視システムのアラーム、ユーザからの問い合わせにより障害の発生が判明します。運用担当者による監視システムを使った障害状況調査、もしくは、ヘルプデスク担当者による問診での障害状況調査が行われ、通常運用ルートに従った、障害状況調査報告、障害発生の広報が行われます。
（２）障害切り分け報告/障害個所特定報告
障害が特定するまでは、複数のM/正・副が並行にシステム単位で障害切り分け作業を行います。基本的にはMの責任と判断の基、正と副は切り分け作業を進め、障害切り分け報告と障害個所特定報告を行います。
統括責任者は複数のMからの報告を受け、全体調整を行います。
（３）回避策の報告/回避策の広報
障害個所の特定から、停止時間が長期に渡ると判断された場合、担当するM/正・副は回避策を策定し統括責任者に報告します。
統括責任者は、回避策が妥当と判断した場合、統括責任者の責任の基、回避策を広報します。
（４）復旧手順確定報告
障害個所を特定後、担当するM/正・副は復旧手順を策定し、復旧に向けての必要事項を統括責任者に報告する。
（５）復旧作業完了報告
復旧作業では、復旧に関わる関係者も含め、Mの管理の基、復旧作業を行います。
復旧作業完了後、復旧に関わる関係者は、Mへ報告を行い、Mは統括責任者に報告を行います。
（６）確認作業完了報告/復旧完了広報
確認作業では、Mの管理の基、正・副による確認作業を行います。確認作業終了後、正・副はMに報告し、Mは統括責任者に報告します。
統括責任者の責任の基、復旧完了を広報します。
・ 命令伝達ルート
（1）復旧作業の指示
復旧手順確定後、Mは、復旧に関わる関係者を集め、関係者及び、正と副に対し復旧作業指示命令を出します。
（２）確認作業の指示
復旧作業完了報告を受けた統括責任者は、Mに確認作業指示命令を出します。Mは正と副に対し、確認作業指示命令を出します。
● トラブルシューティング
障害発生時は錯綜とした状態が想定されるため、トラブルシュートの手順は、極力単純化する必要があります。
以下の準備を事前に行う必要があります。
- システムのリリース前に発生しうる障害を想定し、リカバリ処理と手順の正当性をチェックし、訓練を行い、障害発生時に最短で復旧出来る状態を確立します。
- 過去の障害記録と、それに対する復旧記録からトラブルシューティング集として纏めておきます。トラブルシューティング集は閲覧/検索を可能とし、障害発生時には容易に必要な情報を取る出す事が出来る状態にします。
- 障害切り分けを手順化すると共に、複数の条件の組み合わせ(障害事象の組み合わせ)から、即座に障害個所を特定出来る状態にします。
- マシンを使用する復旧作業では、二次障害を招く恐れがある、コマンド入力による操作は極力避け、事前に復旧のためのスクリプトを作成しておきます。
● 現状状態とシビリティマネージメント
障害復旧への手法として、現状を正しく把握し、次に何が必要で、それを実施することにより、どのような影響があるのかを、繰り返し、繰り返し考え実施し、障害対策時のリスクを軽減して行く方法があります。いわゆる、シビリティマネージメントです。
シビリティマネージメントの基本は現状状態を正確に把握することです。シビリティは便宜的に５段階で定義することとします。障害時には、シビリティをより低い状態にするための対策を講じ、実施し、いずれはリスクが無い(シビリティ0)状態にしていきます。シビリティ毎の状態例を以下に記します。
| シビリティ4 |
即座に対応しなければ、被害が拡大し、ビジネス損失を招く恐れがある状態で回避策(Workaround)がなく、かつ復旧へのプロセスも明確でない状態 |
| シビリティ3 |
障害が与える影響が非常に重大であり、復旧へのプロセスは明確ではないが、回避案(Workaround)がある状態。 |
| シビリティ2 |
障害が与える影響は重大であるが、回避案(Workaround)があり、かつ復旧へのプロセスが明確にされている状態。 |
| シビリティ1 |
障害は発生しているが、アラート状態で与える影響が軽微な状態。 |
| シビリティ0 |
通常運用の状態。 |
障害発生時には、当該シビリティマネージメントを適用し、対策を行うものとします。
|
|
|
|
