IBM Cloud Pak for Multicloud Managementシリーズ(第1弾)"Monitoring"
投稿者：小野 一真
第1回 IBM Cloud PaksとIBM Cloud Pak for Multicloud Managementについて
初めまして。NI+C小野です。
本ブログでは私が今年度より担当しているIBM Cloud Paksやコンテナ技術について、そこで得た知識や学びを紹介していきます。
更新頻度は月1~2回の更新を考えており、各ソフトウェアの検証結果やメリットをお伝えしていきます。
そして記念すべき第1回ではIBM Cloud Paks(以下Paks)のIBM Cloud Pak for Multicloud Management(以下MCM)についてご紹介します。
目次
・IBM Cloud Paksとは？IBM Cloud Pak for Multicloud Managementってなんだ？
IBM Cloud Paksとは？IBM Cloud Pak for Multicloud Managementってなんだ？
まず初めにそもそもIBM Cloud Paksとはなになのか？という方もいらっしゃると思いますのでIBM Cloud Paksの説明をさせて頂きます。
まずIBMさんの説明から見てみましょう。
企業はコンテナやKubernetes を超えて、稼働しているシステム全体を調整・統合し、アプリケーションの管理、安全性、ガバナンスを提供する必要があります。効率性や回復力を高めながら、コストを削減し、ROI を高めていく必要があります。IBM Cloud™ Paksは、エンタープライズのためのコンテナ化されたソフトウェア・ソリューションです。オープンで、より迅速かつ安全に重要なビジネス・アプリケーションをどんなクラウドへも移行する方法を提供します。それぞれのIBM Cloud Pak™は、コンテナ化されたIBMミドルウェアと共通インテグレーション層上の開発・管理用共通ソフトウェア・サービスが含まれています。IBM Cloud Paksは、開発時間を最大で84%短縮し、運用コストを最大で75%削減するように設計されています。IBM Cloud Paks*は、Red Hat® OpenShift®が稼働するあらゆるところで稼働でき、Red Hat OpenShift on IBM Cloudでの生産性とパフォーマンスが最適化されています。(IBM HPより抜粋)
長いですね…
そこで私なりに簡単にまとめてみました。
IBM Cloud Paksとはコンテナ化された6つのIBMソフトウェア群であり、ユースケース別にまとめられたIBMソフトウェアとRed Hat OpenShiftのセットで提供されるソフトウェアソリューションです。
つまり6つのユースケース別にまとめられたソフトウェアのバリューパックですね。
ソフトウェア名称は以下の通りとなっており幅広いユースケースに対応できるものとなっております。
- IBM Cloud Pak for Applications
- IBM Cloud Pak for Multicloud Management
- IBM Cloud Pak for Integration
- IBM Cloud Pak for Automation
- IBM Cloud Pak for Data
- IBM Cloud Pak for Security
各種簡単な説明をすると、
- IBM Cloud Pak for Applicationsは新規クラウドネィティブアプリケーションの開発や既存アプリケーションのモダナイズをするためのソフトウェアを提供します。
- IBM Cloud Pak for Multicloud Managementは複雑化するハイブリット・マルチクラウド環境を統合管理し、運用の自動化を推進するソフトウェアを提供します。
- IBM Cloud Pak for Integrationは複数のクラウドにまたがるアプリケーションとデータの連携をサポートするソフトウェアを提供します。
- IBM Cloud Pak for Automationはお客様業務環境(文書の作成やワークフロー管理など)を自動化し、AIによる業務の最適化を図ることで業務の迅速化やヒューマンエラーの防止を実現するソフトウェアを提供します。
- IBM Cloud Pak for Dataは企業のデータ収集や分析、そして組織全体にAIを組み込むソフトウェアを提供します。
- IBM Cloud Pak for Securityは様々な環境に存在する、セキュリティーデータやツールを統合するソフトウェアを提供します。
そして今回取り扱うのがこの6つのうちのひとつである
IBM Cloud Pak for Multicloud Managementです。
MCMにはソフトウェアが大きく分けて3つあります。
- 1つ目がMCM COREです。
マルチクラウド環境にあるKubernetesクラスタを一括管理するソフトウェアです。アプリケーションの移動やメンテナンスをスムーズに実行し、管理者の負担を軽減します。
対象としてはAWSやGCP、Azureなどのパブリッククラウドベンダーが提供するKubernete環境やオンプレミスに構築したKubernete環境に対応しており、それらを統合管理することが可能です。 - 2つ目がInfrastructure Managementです。
マルチクラウドの環境全てをGUI上で一括管理するソフトウェアです。
各クラウド専用のUIを通さずにインフラの変更ができるため特定クラウドへの依存やクラウドごとの専門操作を回避します。
こちらも対象としてAWSやGCP、Azureなどのパブリッククラウドベンダーが提供するIaaSやVMwareに対応しており、それらの各UIを通さずインフラの変更が可能です。 - 3つ目がMonitoringです。
各種パブリッククラウドベンダーのIaaSや他社SaaS監視サービス、オンプレミスなどからイベントを収集・集約を行い、各イベント/インシデントの相関処理、優先順位付け、問題解決を統合管理するソフトウェアです。集約したイベントやインシデントをコラボレーションツール(SlackやGitHub、Microsoft Teamsなど)へ連携したり、インシデントへの対応を自動的に処理したりできるのでお客様の運用負担を軽減します。
またInfrastructure ManagementとMonitoringについてはAnsible Automationとの連携も可能となっており、OS・ミドルウェアの設定や何度も対応する反復的な障害対応の自動化を実現することができます。
第1回につきましてはMCMの中でもMonitoringを軸に記載していきます。
実際の導入方法や検証の結果等もお伝えしていきたいと思います。
またMCM COREとInfrastructure Managementに関しても今後記載予定であり、
MCM COREについては11月頃、Infrastructure Managementについては12月頃の更新を予定しております。
Monitoring
・Monitoringとは？
Monitoringとは先ほども説明しましたが、イベントソースよりイベントを集約その後、イベント/インシデントの相関処理、優先順位付け、問題解決を統合管理するソフトウェアです。
現在のIT事情としてイベントソースを出力する環境(クラウドサービス、外部の監視ツールなど)が多数あり、それらのイベントやインシデント通知がバラバラかつ大量に通知されるため重要な通知を見落としてしまったり、イベントソースごとにポータルにログインして状況の確認を行う必要があります。
これらは煩雑かつ非効率的なので運用の負荷を軽減することを目的にMonitoringは誕生しました。
今回は実際にMonitoringの検証を行ったのでその際のまとめを記載します。
・Monitoring導入手順、検証結果
ここからは実際の導入手順について記載します。
今回は第1回ということもあり、Monitoringの土台となるRed Hat OpenShiftとMCMの導入も説明したいと思います。
では早速今回の検証で利用する大まかな構成をご説明します。
今回は大きく5つの構成となっております。
まず基盤となるIBM CloudのベアメタルサーバにVMware vSphereを導入しました。
そしてVMware vSphere上の仮想マシンにOpenShiftを導入し、MCM、Monitoringの順で導入しました。
〈構成〉
・Monitoring
・MCM
・OpenShift
・VMware vSphere
・ベアメタルサーバ(IBM Cloud)
そして今回の導入の流れとしましては、以下の様な流れで行っていきます。
Red Hat OpenShiftの導入/設定
↓
MCM・Monitoring導入/設定
↓
Monitoringの検証
また、今回の作業にあたり前提条件は下記の通りとなっております。
・インストール作業用PCが準備済みであること
・環境に接続可能なインターネット環境が設定済みであること
・OpenShiftの導入先が設定済みであること(ベアメタルサーバとVMware環境の設定)
では早速Red Hat OpenShiftの導入からご説明します。
・Red Hat OpenShift導入
Red Hat OpenShiftの導入ではこちらのRed HatさんのHPを参考に導入しました。
(https://docs.openshift.com/container-platform/4.3/welcome/index.html)Red Hat OpenShiftについてはこちらのHPを参考にすることで問題なく導入できました。
導入自体は全てCLIで行い、HPの方に記載されている手順に従ってコマンドを入力していきました。
-MCM・Monitoring導入手順
MCM・Monitoringの導入手順はオンライン導入とオフライン導入があり今回はオンライン導入にて実施しました。
導入の方法としてはGUI、CLIの両方に対応しており、GUIであれば私でも簡単に導入することができました。
MCM、Monitoringの導入ではIBMさんのIBM Knowledge Centerを参考に導入しました。(ibm.com/support/knowledgecenter/ja/SSFC4F_2.0.0/install/online_install.html)
<手順抜粋＞
1.IBM Cloud Pak for Multicloud Management のインストールの準備
2.IBM Cloud Pak for Multicloud Management の名前空間の作成
3.ライセンスのあるレジストリーの秘密の作成
4.インストーラー・カタログ・ソースの作成
5.インストーラー・オペレーターの作成
6.IBM Cloud Pak for Multicloud Management のインストール
-単純インストール
-拡張インストール
7.インストールの検証
8.consoleへのアクセス
ほぼ問題は無かったのですが、注意点がありましたので次項にまとめました。
–MCM導入時の注意点
手順6では記載のあるように単純インストールと拡張インストールがあります。
2つの違いはyamlをデフォルトのまま使用するか、変更するかであり、
単純インストールではデフォルトで使用し、拡張インストールではyamlを変更します。
また、単純インストールではMonitoringが導入されません。
なので今回はyamlを変更する拡張インストールで実施しました。
拡張インストールのyaml設定変更方法は
手順5を終えると以下のような画面に行けるようになり、Create Installationを選択するとyaml変更画面へアクセスできるようになります。
実際のyaml変更画面はこちらとなっております。
最初はデフォルトのyamlが記載されているので、変更箇所を直接GUI上から変更していきます。
また、変更済みのyamlファイルを直接アップロードして適応することも可能です。
こちらは実際に変更したyamlの抜粋となっております。
yaml(デフォルト)
apiVersion: orchestrator.management.ibm.com/v1alpha1
kind: Installation
metadata:
name: ibm-management
namespace: cp4mcm
spec:
storageClass: ”
imagePullSecret: ibm-management-pull-secret
license:
accept: false
mcmCoreDisabled: false
pakModules:
– config:
～～～～～～～～～～～～～～～～～～～～～～～～～～～～
enabled: false
name: monitoring
– config:
yaml(修正抜粋)
apiVersion: orchestrator.management.ibm.com/v1alpha1
kind: Installation
metadata:
name: cp4mcm-install
namespace: cp4mcm
spec:
storageClass: managed-nfs-storage
imagePullSecret: cp4mcm-secret
license:
accept: true
mcmCoreDisabled: false
pakModules:
– config:
～～～～～～～～～～～～～～～～～～～～～～～～～～～～
enabled: true→trueにしてMonitoringを有効にしました。
name: monitoring
– config:
yamlの変更が完了後、左下にあるCreateボタンを押下してください。
すると、MCMとMonitoringの導入が開始され、約15分程度で導入が完了します。
導入の進捗を確認するにはOperatorHubのInstalled Operatorsから確認が可能です。
Statusが“Updating”から”Succeeded”となればMCMとMonitoringの導入が完了です。
今回の導入ではMCMとMonitoringを同時に導入しました。
しかしMCMだけを先に導入して後からMonitoringを導入することも可能です。
MCMを導入したがMonitoringの導入を忘れたから最初からやり直しということは無いので安心してください。
方法としてはInstalled OperatorsからMCMを選択、するとyamlタブがあるので押下してください。
yamlタブを選択すると下記のようなyaml変更画面にアクセスできます。
こちらのyamlは手順抜粋に表記された手順６のyamlと同じものなので、同様の変更方法で変更を行い適用するだけでMonitoringの導入ができます。
変更が完了したら左下にあるSaveを押下してください。
-Monitoring検証内容
今回はMonitoringにて実際にイベントやインシデントが発生した場合通知や処理が収集され通知が行われるのか検証を行いました。
こちらは検証のイメージ図となっています。
・検証の手順
〈手順〉
1.MCMのポータルにある着信統合メニューからイベントソース(AWS・Azure・VMwareなど)の設定
2.MCMのポータルにある発信統合メニューからコラボレーションツール(Slack・Microsoft Teams・GitHubなど)の設定
3.イベントソース(Linuxサーバ)にて障害イベントを発生(今回はLinuxサーバに対してCPU負荷を実施し警告を発報)
4.Monitoringにてイベントの確認
5.コラボレーションツール(Slack)にてイベントの確認
6.障害イベントの解決
7.コラボレーションツール(Slack)にてイベントの解決が通知されているか確認
次に各手順の詳細について記載します。
1.MCMのポータルにある着信統合メニューからイベントソースの設定
Linuxサーバのイベント情報を収集しMonitoringに発報するための着信統合を設定します。
MCMのポータルより着信統合の項目を選択し、利用する統合タイプを選択します。
今回検証で利用するLinuxサーバはAgent型の監視になるため、Monitoring Agentsの項目を選択しました。
次の画面では統合の名前を設定します。
名前とはポータル画面の表示上の名称です。
名前の設定が完了したらファイルのダウンロードを行います。
こちらのファイルは下記URLに導入手順が記載されていますのでLinuxサーバにインストールします。
(ibm.com/support/knowledgecenter/en/SSFC4F_1.3.0/icam/agent_prereq_linux.html)
ファイルのダウンロードが終了次第右下の保存ボタンを押下してください。
2.MCMのポータルにある発信統合メニューからコラボレーションツールの設定
コラボレーションツールに通知するため発信統合を設定します。
今回は発信先としてSlackを利用するのでSlack側の設定から行いました。
Slackにて”アプリを追加する”よりIncoming-WebHookを選択します。
選択後、下記のようなサイトにアクセスしますので、
表示されるWebhook URLをコピーしてください。
その後、画面を下にスクロールすると設定を保存するボタンが表示されるので押下してください。
これでSlack側の設定は終了です。
ここからはMCMのポータルにて発信統合の設定を行いました。
発信統合の項目にSlackのアイコンがありますので選択してください。
次の画面では着信統合と同じように統合の名前を設定します。
URL入力欄ではSlack側で設定したWebhookのURLを入力してください。
最後に右下の保存ボタンを押下してください。
これで設定は完了したので実際にイベントを発生させてみましょう。
3.イベントソース(Linuxサーバ)にてイベントを発生
イベントを発生させるためにLinuxOS上のCPUの負荷をあげてCPU使用率のイベントを発生させました。
4.Monitoringにてイベントの確認
先ほど発生させたイベントがMonitoringに通知されているか確認するために、MCMのポータルを開きました。
今回はCPUの使用率異常が5分以上経過した場合通知するようにしました。
5分後にインシデントの画面にアクセスするとインシデントとして表示されました。
インシデントを選択すると下記のような画面が表示されます。
こちらから詳細な内容等を確認できます。
1.インシデント発生からの時間経過
2.インシデントに対してのアクション状況の確認
3.インシデントの共有状況
5.コラボレーションツール(Slack)にてイベントの確認
コラボレーションツールとして登録したSlackを確認したところにインシデントの発生した通知が届いていました。
SlackからもIncidentの番号やState、障害が発生しているHost name、Team等を確認できます。
またIncident Listを押下すると直接MCMのポータルにアクセスできます。
これによりイベント発生からコラボレーションツールの通知連携までが確認できました。
では次に、イベントを解決した場合の動きを確認してみます。
6.障害イベントの解決
Linuxサーバで起きていたCPU使用率異常を解消しました。
MCMのポータルにて先ほどのインシデントを確認してみると、解決済みの表示が追加されました。
今回はCPU使用率異常が解消されたためイベントが自動的に解決となりました。
他のトリガーとしてはMCMのポータルから手動で解決済みに変更した場合と、他のシステムと連携した自動処理が正常完了した場合等があります。
7.コラボレーションツール(Slack)にてイベントの解決が通知されているか確認
Slackにてインシデントが解決された通知が届いているか確認しました。
Slackには下記のようなイベント解決の通知が届きました。
ー結果ー
LinuxOSの仮想サーバについてCPUに負荷をかけたところ問題なくCPU使用率の負荷を知らせるイベントが通知されました。
またSlack上ではそれらのイベントが発生した時、クローズした時、対応した時に通知されました。
この機能により様々な環境にあるイベントソースのイベントがMCMのポータルにまとめて送られてくるため、確認が容易であると感じました。
また、コラボレーションツール等に通知を送れるためインシデント等が発生した際の確認が早まり、早期の問題対応が可能なことも一つのメリットに思えました。
〈コラム〉イベントソースとコラボレーションツール
イベントソースとコラボレーションツールは下記のリストに対応しています。下記のリストのように多くを取り込むことができます。
またWebhookに対応しているイベントソースやコラボレーションツールであれば、上記に記載されていないイベントソースやコラボレーションツールでも取り込みが可能です。
上記リストに記載したものよりも設定項目は多くなりますが、これにより幅広いイベントソースやコラボレーションツールに対応可能です。
こちらは実際の設定画面となっています。
最後に
本記事でMCMやMonitoringについて少しでも理解を深めるための一助となっていれば幸いです。
本記事の導入方法や機能のご紹介は一部となっております。
今回ご紹介したMonitoringの機能はイベントの通知でしたが、その他にも自動的な担当者の割り当てやAnsible連携を利用した自動化など様々な機能があります。
今後も定期的に情報を発信していきたいと思いますのでお楽しみにしていただければ幸いです。
11月はMCM CORE、12月はInfrastructure Managementを取り上げる予定としています。
この記事に関するご質問等があれば「こちら」からお問い合わせください。
担当者からご連絡させていただきます。
