< 前回の投稿を読む

 

こんにちは、仮想化技術およびクラウドソリューション担当の平原です。クラウドの導入如何に関わらず、問題発生時の調査対象の構成確認や構成設定変更時の影響範囲の特定などを目的にITインフラの構成情報は何らかの方法で管理されていると思います。では、現状これらの情報はどのように管理されているでしょうか?ITサービスマネジメントのベストプラクティスと言われているITILでは、構成情報を集中管理するための要素としてCMDB(構成管理データベース)が定義されていますが、これもは何か実際のデータベースシステムを構築して運用すべきものではなく、Excelシートなどのいわゆる台帳管理であったとしても唯一の情報として正しく管理されていれば、それは立派なCMDBとして機能します。そして多くのお客様がこのExcelシートによる手作業での管理を採用されているのはないでしょうか?

manual_cfg_mgmt.png

クラウド導入においてのもう1つの悩みは、インフラそのものを置き換え、自動化するだけではその効果は限定的であり、従来の運用フローとどのように連携するのか?そして、そもそも従来の運用がクラウドとの連携にあたって一気通貫での自動化の阻害要因となるのであれば、運用そのものを見直すというところにまで考えを拡げる必要があります。この点でこの手作業での構成管理プロセスというのは多くのケースで変革を迫られる領域の1つと言えます。

 

一番簡単な方法としては、定期的なタイミングでvRealize AutomationやvCenter Serverからプロビジョニング済の仮想マシン情報を取り出し、それを構成管理のマスターにすることですが、いつプロビジョニングが実行されるか分からないクラウド環境においては、必ずしも取り出した情報と現況の一致を保証することは難しく、また、構成管理の適用範囲も極めて限定されるため、特に構成アイテムの関連性をもとに影響範囲の特定などでは支障をきたす可能性があります。

 

もう1つの方法は、新たなCMDBを構築し、API連携等によって仮想マシンのプロビジョニングやデコミッショニングのタイミングで自動で更新可能な仕組みを検討することです。この方法は、他のインフラ領域の構成情報と統合でき、相互関連性を持たせられること。担当者や保守契約情報など機器から自動収集される以外の情報を柔軟に付加、管理できることなどから、高いレベルの運用性を持たせることが可能ですが、

  • そもそもCMDBとしてどんなツールを採用するのか?
  • 構成管理の範囲をどこまで拡げ、スキーマをどのように定義するのか?
  • 既存の構成情報の取り込み(インポート)はどうするのか?
  • 他の運用管理ツール(インシデント管理、ヘルプデスク等)との連携はどうするのか?

など、クラウドのインフラ導入に匹敵するだけの工数を想定しておく必要があるかもしれません。

 

このため、このようなITサービスマネジメントやビジネスワークフローをSaaS(Software as a Service)として提供する会社も現れてきており、米国ではServiceNowというSaaSの利用シェアが高まっているようです。Enterprise Hybrid Cloudにおいても欧米市場における利用シェアを鑑みて、ITSM連携のリファレンスアーキテクチャにServiceNowを採用しています。

ServiceNowの概要はこちらです(ServiceNow社のホームページに飛びます)

 

連携イメージとしては、下記のイメージのとおりです。Enterprise Hybrid Cloud環境には、vRealize OrchestratorにDELL EMCが開発したServiceNow連携検証済のワークフローが導入され、vRealize Automationのブループリントからワークフロー実行がトリガされる仕組みです。Enterprise Hybrid Cloudのオンプレミス環境とServiceNowとの情報のやり取りは、ServiceNow社が提供するMID(Management, Instrumentation, and Discovery)サーバをデータセンター上に配置することにより、HTTPSの通信許可を与えるだけで可能となります。

ehc_snow_integration.png

では、vRealize側の画面を見てみましょう。まずはvRealize Orchestratorですが、ここにはDELL EMCによる開発済のワークフローが導入されます。標準ユースケースの導入であれば特にカスタマイズなく導入が行われます。ここでのワークフローに与えられているIDはvRealize Automation側での設定で必要となってきます。

workflow1.png

次にvRealize Automation側でサービスカタログ実行とServiceNow連携ワークフローの実行を紐付けます。これは毎回のように出てくるBuild ProfileBlueprint上で設定されます。Buildprofileでは、仮想マシンのライフサイクルステータス(作成、除却など)を示すWorkflow Stub(ワークフロースタブ)という情報に対して、先ほどのvRealize OrchestratorワークフローのIDを紐付けます。ここでは"ServiceNow Integration"という名前でBuildprofileを作成しました。

buildprofile2.png

次にBlueprintの作成または更新です。重要なのはPropertiesタブの部分です。ここに先ほど作成したBuild Profileである"ServiceNow Integration"が表示されているはずですのでこれにチェックを入れます。実際のところBlueprintへの仕込みはこれだけです。

blueprint1.png


blueprint2.png

一見分かりませんが、ServiceNowと連携するサービスカタログの完成です。

provision1.png

では、実際にプロビジョニングしてみましょう。Propertiesタブに先ほどのBuildprofileの設定内容が反映されています。

provision2.png

 

provision3.png

リクエストステータスがSuccessfulで新しい仮想マシンが作成されました。ここの仮想マシン名"BLRPOCLIN043"に着目しておいてください。

provision5.png

 

provision7.png

ServiceNowのポータルにアクセスしてみます。無事、仮想マシン"BLRPOCLIN043"が登録されていました。

snow1.png

 

snow2.png

 

snow3.png

次に仮想マシンの除却を行います。仮想マシンのアイテムを開いて、操作メニューから"Destroy"を選びます。

provision6.png

仮想マシンが問題なく削除されると、ServiceNow側の仮想マシンステータスは"Retired"に変更されました。過去の履歴管理を行う上では仮想マシンが削除されたからといって構成情報も消すわけにはいかないですから...

snow4.png

いかがだったでしょうか?以前のブログでREST APIによる情報取得例を紹介しましたが、実際には情報取得だけでなく、このようなツール間連携もお互いのツール内部にガチガチな造り込みをすることなしに、緩~い感じ(!?)で実現出来てしまいます。いわゆるソフトウェアディファインドやクラウドの特徴でもあるプログラマブルITの好例でしょう。この「プログラマブル」という概念は非常に重要です。これがあるからこそ、どんな複雑な要件に対しても柔軟に基盤を拡張できる、また自分に足らない、出来ないことも他の力を借りて実現できるわけです。AWSが成功をおさめたのも、まさにこの他の力を借りる「エコシステム」を創り上げたことによるものと言えます。

 

Enterprise Hybrid Cloudもまた、お客様のユースケースに役立つサードパーティーインテグレーションを継続的に進めていきます。

  • ServiceNow:ITSMソリューション連携
  • Infoblox:IPAM(IPアドレス管理)ソリューション連携
  • Palo Alto Networks:フォイアウォールソリューション連携
  • Puppet Enterprise:Infrastructure as Code(構成管理自動化)ソリューション連携
  • Chef(計画中):Infrastructure as Code(構成管理自動化)ソリューション連携

 

続きの投稿を読む >