Discoveryで検出されたCIをベースに、タグを用いてService Mappingを作成した場合、横長の構成図となる傾向があります。
さらに、関連するCIが多い場合には、影響範囲に含まれるCIを目視で把握しづらくなり、結果として可視化の効果が低下します。
例：
こんな イメージ：
そこで、関連するCIが多い場合でも、Service Mapping をより分かりやすくするため、CIをグループ化し抽象度を高めるため Dynamic CI Groupを活用したService Mappingの作成手順を文書化しました。
製品マニュアルを確認したものの、体系的に整理された手順を見つけることができなかったため、本内容を参照することで、今後の手順再確認に役立てられればと考えています。
■目次
１．シナリオ
２．CMDB Groups 作成
３．Dynamic CI Group 作成
４．Service Instance 作成
５．Service Mapping 作成
６．Service Mapping 確認。
７．CI 異常時のService Mapping確認
８．CI 復旧時のService Mapping確認
■シナリオ
Aシステムは、複数のLinux／Windowsサーバーで構成されており、Azure上にデプロイされています。
従業員は事業所から業務用ノートPCからは、Aシステムへアクセス可能です。
アクセス経路は、事業所内の無線ルーターからネットワークデータセンターのファイアウォールおよびルーターを経由し、Azure上のAシステムへ到達する構成となっています。
本構成において、ネットワークデータセンターのルーターに障害が発生した場合に、各CIへの影響を、Service Mappingで可視化できる事をゴールとして試しました。
ポンチ絵
Dynamic CI Group を上記ポンチ絵をベースに作成していき、Service Mapping で関係性を可視化します。
ただ、Tags ベースの Service Mapping では階層構造のネットワークトポロジーは表現できない点があるた、図そのものの階層構造を表せない制限があります。
２．CMDB Groups 作成
今回 ４つの Dynamic CI Group を作成するため、対応するCMDB Groups の作成が必要です。
また、前提としてDiscoveryにてCIが検出されている必要があります。
作成手順
ナビゲーションメニュー より CMDB Group を探して開きます。
CMDB Group 一覧が表示されますが、右上の 「New」ボタンを押して、新規作成します。
以下の要領で 事業所無線ルータ、Firewall、ルータ、AシステムのCMDB Group を作成します。
２－１ CMDB グループ名を入力
２－２ Save を行い「CMDB Group Contains Encoded Queries] タブから New を押して、グループ化したいCIを抽出します。以下のようなイメージとなります。
２－３ CMDB Group を２－２の要領でポンチ絵図の通り４点作成します。
・事業所 無線ルータ
・ネットワークセンター ファイアウォール
・ネットワークセンター ルータ
・Aシステム
作成リスト
３．Dynamic CI Group 作成
作成した４つのCMDB Group をベースに ４つの Dynamic CI Group を作成します。
Application Navigator のフィルタに Dynamic CI Groups を入力し、 Configuration 配下の Dynamic CI Groups を開きます。
Dynamic CI Groups 一覧が表示されますので、右上の「New」ボタンを押して、以下のように埋めていきます。
重要なのは、Name と CMDB Group を埋めれば目的が達成できます。
作成後のDynamic CI Groups リスト
４．Service Instance 作成
下準備ができましたので、Service Mapping を作成するための Service Instance を作成します。
Application Navigator のフィルタに Service Instance を入力し、 CSDM 配下の Service Instance を選択します。
選択後、Service Instance 一覧が表示されますので、右上の「New」ボタンを押して進めます。
最初に表示される画面では、Name だけを埋めていきます。今回は 「Aシステム プロダクション」としました。
また Operation Status を「Operation」にしておきます。 初期値のNon-Operation のままだと、後々利用する Service Operation Workspace のService Dashborad に表示されないためです。
重要なのは２番目の箇所です。 Service Popultation Method に 「Tags」を指定し、Tag Base によるServce Mapping 作成を指定します。Tag に利用するKey/Value をそれぞれ A_System_Key / A_System_Value としました。Key/Valulue はアルファニューメリック 制限と空白がNGとなります。
これで進めていき、Servce Instance 作成を完了させます。
５．Service Mapping 作成
いよいよ最後のServce Mapping を作成していきます。
作成した４つの Dynamic CI Group 以下を関連付けます。
・事業所 無線ルータ
・ネットワークセンター ファイアウォール
・ネットワークセンター ルータ
・Aシステム
Application Navigator のフィルタに 「cmdb_key_value.list」 を入力し Enter キーを押します。
Tag Base のServce Mapping 紐づけ用テーブル cmdb_key_value の一覧が表示されます。
右上のNew ボタンを押します。
ここで、
Configuration Item → Dynamic CI Group を指定
Key → Service Instance で作成した Tags のKey を指定 「A_System_Key」
Value → Service Instance で作成した Tags のKey を指定 「A_System_Value」
入力例：
このレコードを Dynamic CI Group ４つ作成します。Insert And Stayを利用すると簡単です。
数が多いと Import Set でまとめて実施するのがよいですが・・・。数が多くなると結果的にService Mapping が横長になり可視性が低下しますので、Dynamic CI Group を活用し手入力で対応できるレベル感になるのが良いと見ています。
６．Service Mapping 確認。
Application Navigator のフィルタに 「Service Operations Workspace」 を入力しService Operations Workspace を開きます。左メニューの□が４つあるアイコン Service Dashborad を開き、Service Instance の一覧がタイル形式で表示されますので、Aシステム プロダクションを選択し、表示されたメニューから「Service Map」 を選択すると、以下のようにService Mappingが表示されます。
７．CI 異常時のService Mapping確認
Aシステムのサーバーが異常発生したと想定し、イベントを手動作成し異常通知をシミレーションします。
結果的にService Mapping がどのようになるか確認します。
並行して、同じネットワークトポロジー構成のBシステムを作成し、影響があるかもみていきます。
まずはイベントによる異常状態を手動作成します。
Application Navigator のフィルタに 「All Events」 を入力し All Events を開きます。当日のイベント一覧が表示されますので、右上の「New」ボタンを押し新規イベントを作成します。
任意の値を入れますが、ソースフィールドは「Zabbix」、メッセージキーには「ユニークな英数字」（なんでもよいです）、重大度を「Critical」、ノードにCIの名前をいれて送信します。
1分待機し、Application NavigatorからAll Alertsを選択し、アラートが作成されていることを確認します。（構成アイテムにちゃんと入っているか確認）
このアラートをクローズさせれば赤からノーマルに戻ります。イベントはそのままでOKです。
＊イベントのソースにZabbixとしたのはあくまでお試しとして、OOTBのイベントルール（Zabbix用）を使っているからです。おそらく空欄でもなんらかのイベントルールが適用され、正しくアラートを作成すると思いますが、確実に作るためにZabbixを選びました。
Service Opertions Workspace → Service Dashboard にて、Aシステムが異常である点が確認できます。
さらにService Map からはどこで異常が発生したか確認可能。
ただ、同一ネットワーク構成の Bシステム では異常発生していない点を確認できます。
仮に共通で利用しているネットワークのどこかしらに異常があれば、A,B 両方のシステムで異常発生となります。
８．CI 復旧時のService Mapping確認
最後に作成されたAlert をクローズし、エラー解除されるか確認します。
Application NavigatorからAll Alertsを選択し、作成したアラートを開きクローズします。
これで Service Opertions Workspace → Service Dashboard から該当Service Instance の正常ステータスを確認できます。
