お役立ち資料/ホワイトペーパー >
「構成管理」を改めて知り、実践し、極めよう（ホワイトペーパー Vol.8）
「構成管理」を改めて知り、実践し、極めよう
構成管理の意義は「ITインフラの構成要素を可視化し、変化に対して柔軟かつ迅速に対応するため」だと言われても、ピンとくる方は少ないのではないでしょうか？
ある企業の通販サイトは、ECサーバーパッケージを稼働させて運用していました。ある時、脆弱性の存在を外部から指摘され、その対応のためにはJavaのバージョンを上げる必要があると判明しました。
さて、いざJavaのバージョンを上げようとすると、今度はLinux OSのバージョンも更新しないと導入できないことがわかりました。
しかし、それだけでは終わらず、次のハードルが待ち構えていました。Linux OSを最新版に入れ替えようとすると、サーバー・ハードウェアのリソース不足に陥ってしまったのです。
結局、脆弱性対策をきっかけに、最終的にサーバー・ハードウェアの総入れ替えにまで波及してしまうことになりました。
新規サーバーの購入、OSの導入、アプリケーションのマイグレーション検証等、1日や2日で済むはずもなく、担当者はその間、気が休まる暇がなかったそうです。
その企業は、この件がきっかけで構成管理の必要性を認識されたようです。
どこに、何があり、それが今どうなっているのか？
特にセキュリティ問題が取り沙汰される昨今では、その重要性はますます高まっています。
システムの構成要素である、アプリケーション、ミドルウェア、Java、OS、サーバー・ハードウェアの最新情報とEOL、脆弱性情報と照らし合わせながら、計画的にITインフラを維持することが必要です。
１．構成管理の目的
「ITサービスの滞りない提供を行うこと」が最終的な目的になりますが、そのためには、システム構成要素のライフサイクルや整合性を管理すること。そして、どこに何があり、それぞれがどうなっているかを可視化することが必要です。これによって素早く、確実なアクションが起こせるようになります。
例えば、オンプレからパブリッククラウドに移行する際、最新の構成情報が正しくなかったり、収集に時間がかかっていたりすると、パブリッククラウドでどのくらいのリソースが必要なのか、いくらぐらいのコストが見込まれるのかを正しく試算することが難しくなります。
また、構成管理の情報は、最近ではソフトウェア・ライセンス利用時のコンプライアンス違反防止のため、資産管理の基礎情報としても利用されています。ライセンスのカウントでは、CPUのコア数をいくつ使っているかに応じて課金額が変わる場合があり、適切な管理が必要です。
２．構成管理で期待される効果
構成管理で期待される効果には、どのようなものがあるのでしょうか。
まず、システム追加・変更時に、既存のシステム構成要素への影響度をすばやく認識できること、そしてプラットフォームを移行する場合、正確な評価が可能になることが挙げられるでしょう。
自社インフラの構成が現在どうなっているのかがわからないと、正しい計画をたてることはできません。まずやらなければならないことは、最新の構成情報を定期的に把握することで、自社インフラの再構築やオンプレからクラウドへの移行には必ず必要になります。
次に、現状のシステム構成要素を知っておくことで、障害発生の未然防止および障害発生時の早期解決が図れます。ハードウェアについては、定期的な交換やファームウェアのアップデートが必要ですし、ソフトウェアにしてもパッチの適用だけでなく、関連するOSやミドルウェア等との依存関係を知っておくことで、問題の発生を未然に防げます。
たとえば、OpenSSLの特定のバージョンでの脆弱性の問題や、SSL証明書の有効期限切れによる「エラーが出てサイトが表示されません！」が出て、サイトにアクセスできない問題です。
社会的な問題になっている脆弱性への対策については、セキュリティ問題が公表された時に、すばやい対応ができるようになります。どこに該当するOSやアプリケーションのバージョンがあるのか、どれくらいの数があるのか、パッチ適用はどう行っていくのかなど、短時間で状況を把握し、計画的に対策の検討が行なえます。また、経営者の不安を和らげることにもつながります。
そして、ソフトウェアやハードウェアにはベンダーサポートでの寿命があるため、EOS/EOLを把握し、サポート切れに向けた着実な対応準備の計画が立てられるようになります。
最後に、資産管理的な要素として、今ライセンスをどれくらい利用しているのか、契約ではどうなっているのか、についても把握することで、コンプライアンス違反を未然に防ぐことができます。
このように、構成管理を適切に行うことで、最終的には業務効率化、投資対効果の最大化につなげることができるのではないでしょうか。
３. 構成管理の目的実現のために必要な考え方
そこで、必要な構成情報をリストアップする方法をご紹介します。
まず、構成管理で実現する目的をイメージし、それを実現するために必要なコトをブレークダウンして芋づる式に抽出していきます。そして、それぞれに必要な情報や手段をリストアップします。
図１は、構成管理の目的とそれを実現するために必要なコトと情報の抽出についての関連イメージを示しています。このようにすることでヌケモレを防げますし、必要なコトや情報の改廃も簡単にできます。
４．最新の情報を収集
次に、必要な情報が決まったら、それをどう収集するかを決めます。
例えば、基本的な情報として、利用OS/ソフトウェア、バージョン、本数などがあります。
利用ハードウェアの型番やCPU、メモリ、HDDなどのスペックなども必要でしょう。ハードウェアの場合、どこまでのブレークダウンが必要かも検討が必要です。
そして、利用状況としては、最終再起動日時や最終アクセス状況などが必要になるかもしれません。
５．効率的な情報収集
これらの構成情報を手で収集しExcelで管理するとなると、相当骨が折れます。
対象となる機器や収集しなければならない情報が多い場合は収集スパンが広がりがちになります。結果として、集計タイミングが四半期毎とか、下手をすると１年前ということもあるようです。
このため、できるだけ多くの情報を自動的に収集できることが肝要です。また、見たい時にすぐに確認できるようなダッシュボードのような手段も必要でしょう。
自動的に収集できればそれが一番ですが、そうはいかないものもあります。そこで、収集したい構成情報を以下のように区分します。
- ツールのデフォルト機能で自動収集できるもの
- ツールから個別のスクリプトを送って返り値として自動収集できるもの
- 手作業で記入するもの
- これらの情報を収集後に2次加工が必要なもの
そして、収集した情報をCMDB（構成情報DB）に登録するか、EXCEL等で管理するかの検討も必要です。
６．構成情報の収集に便利なPOLESTAR Automation
運用自動化ツールのPOLESTAR Automationでは、以下のようにハードウェア、OS、アプリケーション等の情報を自動で収集でき、ダッシュボードからの確認ができます。
また、対象から直接収集できないような、担当者や設置ロケーション、マニュアルへのリンクなどのような情報はPOLESTAR Automationにおけるデバイス毎のプロパティ情報として紐付けすることで、レポーティング時に表示させることができます。
| 区分 | 項目 | 説明 |
|---|---|---|
| CPUs | Count | 論理CPU Coreの数 |
| Model | CPUのモデル名 | |
| Vendor | CPUベンダ | |
| Clock(MHz) | CPUのClock | |
| SocketCount | CPU Socket（or slot）数（物理CPUの数） | |
| PhysicalCoreCount | 物理CPU Coreの数 | |
| ThreadCount | Core当たりのスレッド数 | |
| HyperThread | CPUがIBM製品の場合はSMT、Intelの場合はHyper-Threadingサポート有無確認 （trueの場合サポート) | |
| Disk Groups | Attribute | ディスクグループのプロパティ |
| Value | ディスクグループのプロパティ別の値 | |
| Disks | Name | 個別のディスク名 |
| Capacity(MB) | 個別のディスク容量 | |
| Vendor | 個別のディスクベンダ | |
| Filesystems | Name | 個別のファイルシステム名 |
| Capacity(KB) | 個別のファイルシステム容量 | |
| DriveName | 個別のファイルシステム物理ドライブ名 | |
| Memory | Attribute | メモリのプロパティ |
| Value | 実装されているメモリ容量 | |
| Network Interfaces | Name | ネットワークインタフェース名 |
| Bandwidth(Kbps) | ネットワークインタフェースに割り当てられた帯域幅 | |
| Ip | ネットワークインタフェースに割り当てられたIPアドレス | |
| Mac | ネットワークインタフェースに割り当てられたMacアドレス | |
| Mtu(Octet) | ネットワークインタフェースに割り当てられたMTU | |
| Managed | ネットワークインタフェースの管理有無 | |
| Duplex | ネットワークインタフェースに設定されているDuplex | |
| Netmask | ネットワークインタフェースに割り当てられているNetmask | |
| Operating System | HostName | サーバーのホスト名 |
| LastBootupTime | サーバーの起動時間 | |
| ElapsedDate(Days) | サーバーを起動してからの経過時間 | |
| Model | サーバーのモデル | |
| OsBit | サーバーのOS Bit | |
| OsName | サーバーOSの種別 | |
| OsVersion | サーバーOSのバージョン | |
| PatchLevel | サーバーOSのパッチレベル | |
| SerialNo | サーバーのシリアル番号 | |
| Timezone | サーバーのタイムゾーン | |
| HostID | サーバーのHostID | |
| LastInstallDate | Windowsがアップデートされた最終日時 | |
| LastInstallelapsedDate(Days) | Windowsがアップデートされた最終日時からの経過時間 | |
| Vendor | サーバーのベンダ |
| プロパティ | 説明 |
|---|---|
| Name | パッケージ名 |
| InstallDate | インストール日時 |
| PackageType | パッケージのタイプ |
| Vendor | ベンダ |
| Version | バージョン |
| プロパティ | 説明 |
|---|---|
| Name | ソフトウェア名 |
| InstallDate | インストール日付 |
| InstallLocation | インストールされているパス |
| Vendor | ベンダ |
| Version | バージョン |
| プロパティ | 説明 |
|---|---|
| Name | パッチ名 |
| KbArticleID | MSテクニカルドキュメント番号 |
| Product | パッチ該当製品（例：Windows XP、Office 2007など） |
| PublishedDate | 登録日付 |
| Category | パッチ区分（例：Service Packs、Feature Packs、Security Updates、Critical Updates、Updates、Update Rollup など） |
| Size(bytes) | パッチファイルのサイズ |
| UpdateType | アップデートの種類（例：None、Important、Optional） |
| AnalysisDate | パッチ分析日付 |
| InstallDate | パッチ適用日付 |
| Installed | パッチ適用の有無 |
| Restart | 再起動の要不要 |
| Severity | 重要度（例：Critical、Important、Moderate、Low、None） |
| BulletinID | 掲示ID |
| Description | パッチに対する詳細説明 |
| DownloadUrl | パッチファイルのダウンロードURL情報 |
| Excluded | パッチ適用除外の要不要 |
| InfoUrl | パッチ情報URL |
| InteractiveMode | インタラクティブモード設定（TRUEの場合は該当パッチを自動で適用できます。） |
| MasterExcluded | パッチ適用除外の有無 |
| UpdateID | パッチ項目の固有ID(UUIDと類似する形式) |
| 項目 | 説明 |
|---|---|
| Model | 機器のモデル情報、POLESTAR Automationのモデルライブラリに存在しない場合は、Unknownで表示 |
| OsVersion | 機器のOSバージョン情報、POLESTAR Automationで管理されているメーカの機器がない場合は、表示されない可能性もある。 |
| Serial Number | 機器のシリアル番号、機器の種類によって表示されない可能性もある。 |
| SysContact | 機器担当者の連絡先、SNMP OID 1.3.6.1.2.1.1.4で収集 |
| SysDescr | 機器の説明情報、SNMP OID 1.3.6.1.2.1.1.1で収集 |
| SysLocation | 機器の位置情報、SNMP OID 1.3.6.1.2.1.1.6で収集 |
| SysName | 機器名、SNMP OID 1.3.6.1.2.1.1.5で収集 |
| SysObjectID | 機器のsys object id. SNMP OID 1.3.6.1.2.1.1.2で収集 |
| SysUpTime | 機器の起動日時、SNMP OID 1.3.6.1.2.1.1.3で収集 |
| Vendor | 機器のメーカ情報、 POLESTAR Automationのモデルライブラリに存在しない場合は、Unknownで表示 |
| 項目 | 説明 |
|---|---|
| Name | インタフェース名 |
| IfIndex | インタフェースのインデックス |
| OperationalStatus | インタフェースの管理状態 |
| Port | インタフェースのポート番号 |
| Type | インタフェースのタイプ |
| ConnectedIp | 接続されている機器のIPアドレス |
| DeviceName | 接続されている機器 の名称、POLESTAR Automation管理対象のデバイスの場合、リンクで表示される。 |
| VlanName | 接続されている機器のVlan名称 |
| Bandwidth | インタフェースの帯域幅（Kbps） |
| Description | インタフェースの説明 |
| Mtu | インタフェースのMTU(Octet) |
| Netmask | インタフェースのNetmask |
７．POLESTAR Automationで必要な時に、必要な形式でレポーティング
最新の構成情報は、画面やレポートにより、すばやく確認が行えるようにしたいものです。
POLESTAR Automationでは、標準の報告書機能を利用し、定形のテンプレートを使って構成情報の一覧表を作成できます。メールに添付して定期的にレポートを送付できる機能もあり、毎月 第一月曜日午前8：45に定期的なレポーティングをさせるといったことが簡単にできます。
また、添付するファイルの形式はExcel、Word、PDFから選択できます。
図２に、報告書作成機能を利用して作成した構成情報報告書の例を示します。
＞大きい画像を見る
図２ 構成情報報告書
さらにPOLESTAR Automationでは、「ライブオブジェクト照会」といって、任意のプロパティを選択することで一覧表イメージを作成する機能もあります。
デバイスグループと表示したいプロパティをマウスでドラッグ＆ドロップするだけで、一瞬にして一覧表が作成でき、Excelのアイコンをクリックすれば、Excelでのダウンロードも可能です。
また、スクリプトジョブと連動して、収集した結果を一覧表の中に含めることも可能ですので、柔軟に構成情報の一覧表が作成できます。
８．構成管理を再認識し業務の効率化につなげる
このように、POLESTAR Automationで構成情報の収集、集計、レポーティングといった手間のかかる作業を自動的に行うことで、いつでも最新の構成情報を手許に置くことができ、インフラ運用における業務の効率化と有効利用による投資対効果の最大化につなげていただくことができます。
以上
＜おすすめコンテンツ＞
・導入事例 大手通信キャリア様構成管理自動化事例
