IBM Power Virtual Serverの監視ソリューション　～IBM Cloudの標準的な監視サービスでPVSを監視できるのか？

Text＝棚橋 あずみ 日本アイ・ビー・エム システムズ・エンジニアリング

本稿では、オンプレミスにてIBM Power（以下、Power）およびIAサーバー上で稼働しているシステムをIBM Power Virtual Server（以下、PVS）およびIBM Cloud環境へ移行する際に想定される移行パターンについて触れ、そのような構成で実装可能な監視方式を紹介する。

オンプレミスからクラウドへの移行アプローチ　

IBM CloudのIaaSサービスであるPVSの東京リージョンがサービスを開始してから2年が経過し、サービスの利用やオンプレミス環境のクラウド移行を検討されるユーザーが増加している。

一般的に、オンプレミスのITインフラのクラウドへの移行では大きく、「リフト」と「シフト」という2つのアプローチが存在する。

リフトは、オンプレミスで稼働している既存アプリケーションを改修なしで、そのままクラウドにマイグレーションするアプローチである。それに対してシフトは、アプリケーションをモダナイズするアプローチであり、その例としてコンテナ化やマイクロサービス化が挙げられる。

クラウドへの移行は、既存システムのサーバーやアプリケーションの性質に応じて、段階を踏んで実施することが多く、一部をオンプレミスに残すケースや、リフトするサーバーおよびリフト&シフトするサーバーを組み合わせて稼働させるケースも存在する。

IAサーバーとPowerで稼働しているオンプレミス環境のシステムをクラウドへ移行するケースでも、どのようなアプローチを選択するかの検討が必要である。

クラウド環境にも監視は必要

クラウド環境上のシステムであっても、安定稼働のためには監視の実装が欠かせない。そのため、オンプレミス環境をクラウド環境へ移行する際には、監視の実装方法も考慮しておく必要がある。

最適な監視方法は、該当システムを移行する際に選択したアプローチやシステム構成によって異なる。通常、多くのクラウドサービスでは、監視のためのサービスが提供されており、これを使用することで運用コストの削減につながる。

特にクラウドサービス上でコンテナ化したアプリケーションを動かしている場合には、サービスやコンテナの特性から、クラウドサービスで提供される監視の仕組みを利用する方法が合理的である。

それに対して、サーバーを単純にシフトしたシステムや、一部のサーバーをオンプレミスに残すような構成では、既存システムで使用している監視方法を踏襲することが設計や運用の観点から有利になると考えられる。

オンプレミスからクラウドへ
想定される2つのパターンと監視方式　

以上を踏まえて、オンプレミス環境をIBM CloudおよびPVSへ移行するケースを考えてみる。

現行のオンプレミス環境では、IAサーバー上にAPサーバー、IBM Power上にDBサーバーが存在し、IA サーバーをIBM Cloudへ、DBサーバーをPVSへ移行すると仮定する。この場合に想定されるクラウドへの移行パターンと監視方式を、図表1に示した。

前述したクラウド化へのアプローチに基づくと、クラウド環境への移行パターンは以下の2つが想定される。

① オンプレミスの仮想サーバーをクラウドの仮想サーバーにそのまま移行するパターン
APサーバーはIBM Cloud、DBサーバーはPVSへそれぞれリフトする。

② 移行のタイミングでアプリケーションのモダナイズを行うパターン
APサーバーはコンテナ化してIBM Cloudにリフト&シフトし、DBサーバーはそのままPVSへリフトする。

オンプレミス環境の構成をそのまま移行する①のリフトパターンでは、設計コストや運用手順の学習コスト等を考慮すると、監視方法は現行環境で採用している仕組みを踏襲することが効率的と考えられる。

ただしこの場合、クラウド環境へ移行後も、ユーザーによる監視サーバーの維持管理が求められる。

一方、②のパターンでは、コンテナ化されたアプリケーションの監視を実装する必要がある。IBM Cloudでも他のクラウドサービスと同様に、システム監視のためのサービスが複数提供されており、コンテナ環境の監視にも利用できる。

したがってIBM Cloud上の仮想サーバーおよびアプリケーションは、IBM Cloudの標準サービスで監視するのが合理的といえる。

この場合、PVS上の仮想サーバーもIBM Cloudの標準サービスで監視できれば、すべての仮想サーバーを共通した仕組みで統合的に監視でき、運用作業が効率化される。

PVSはIBM Cloudの標準サービスで監視できるのか？

PVSはIBM CloudのIaaSサービスだが、マニュアルにも記載があるように、IBM Cloudとはネットワーク的に切り離されており、IBM Cloudサービスと接続するにはDirect Link Connectの構成が必要である。

また、これまでIBM Cloud の標準サービスによりPVSを監視することの可否については、まとまったドキュメントが存在していなかった。そのため、私たちはIBM Cloud の標準サービスによりPVS環境を監視する実装の可否を検証した。

＜参考情報＞　IBM Cloud Docs : Power Systems Virtual Server とは?

IBM Cloud提供の監視サービスと監視項目

IBM Cloudの標準サービスによるPVSの監視可否を述べる前に、IBM Cloudで提供されている監視の標準サービスと機能を簡単に紹介する。

IBM Cloudでは、以下の3つのサービスが提供されている。

IBM Cloud Monitoring

・監視対象サーバーへエージェントを導入することで、さまざまなメトリクスの収集・管理が可能
・リアルタイムのパフォーマンス監視およびトラブルシューティングに使用できる
・事前に設定した条件に応じたアラート通知が可能 (障害やパフォーマンス低下時に通知できる)

＜参考情報＞　IBM Cloud Docs : IBM Cloud Monitoring入門チュートリアル

IBM Cloud Log Analysis

・IBM Cloud内外のシステムやアプリケーションのログデータの収集・管理が可能
・syslogやrsyslogの転送 (エージェントレスでも可能)
・エージェントを使用した、インスタンスやKubernetesクラスタのログ収集
・Ingestion REST APIやライブラリーを使用したアプリケーションログの収集
・事前に設定した条件に応じたアラート通知が可能（特定の文字列に該当する場合に通知できる）

＜参考情報＞　IBM Cloud Docs : IBM Cloud Log Analysis入門チュートリアル

IBM Cloud Activity Tracker

・IBM Cloud上でのアクティビティレコードの取得やモニタが可能
・収集されるイベントは、Cloud Auditing Data Federation (CADF) 標準に準拠
・事前に設定した条件に応じたアラート通知が可能

＜参考情報＞　IBM Cloud Docs : IBM Cloud Activity Tracker 入門

 

クラウド環境で必要となる監視項目は、リソース監視、死活監視、プロセス監視、ログ監視と監査証跡の取得が挙げられる。それぞれを上記のサービスで実装する方法を、図表2にまとめた。

リソース監視、死活監視、およびプロセス監視はIBM Cloud Monitoringによって実施できる。

またプロセス監視は、IBM Cloud Log Analysisのログ転送の機能を利用し、OS上で稼働するスクリプトと組み合わせることでも実装できる。

具体的には、仮想サーバー上でプロセス状況を確認するスクリプトを定期的に実行して、その結果をログに出力し、このログをIBM Cloud Log Analysisへ転送する。IBM Cloud Log Analysisにて事前に通知設定しておくことで、プロセス状況に異常が生じた場合にアラートを通知できる。

ログ監視はIBM Cloud Log Analysis、監査証跡の取得はIBM Cloud Activity Trackerで実施できる。

IBM Cloudの監視サービスによるPVSの監視可否

IBM Cloudで提供されている監視の標準サービスを利用し、PVS環境の仮想サーバーを監視可能かどうかについて調査・検証した。その結果を、図表3に示す。

調査の結果、IBM Cloud MonitoringはPower環境で使用可能なエージェントが存在しないため、PVS環境では使用できないことがわかった。

一方、IBM Cloud Log Analysisは既存のエージェントをコンパイルすることで、PVS環境の仮想サーバーに導入できる。実環境にてエージェントを導入し、ログを転送できると確認できた。

IBM Cloud Activity Trackerは、IBM Cloud上の仮想サーバーと同様に、IBM Cloud Activity Trackerのコンソールから設定を実施することで証跡を取得できた。

以上から、プロセス監視、ログ監視および証跡取得はIBM Cloud提供の監視の標準サービスで実施可能だが、リソース監視や死活監視は他の方法による実装を検討する必要があると判明した。

リソース監視と死活監視の実装例　

では、リソース監視と死活監視はどのような実装できるのだろうか。

例として、図表4のようにPower環境で使用可能なモジュールやオープンソフトウェアを組み合わせる構成が挙げられる。

リソース監視は、性能情報収集モジュールであるnjmonで収集した情報を時系列データベースであるInfluxDBに蓄積し、データの可視化ツールであるGrafanaによりグラフ化する構成が考えられる。

njmonはOS上で稼働し、nmonと同等 (またはそれ以上) の統計情報と構成情報を収集するモジュールであり、AIX用とLinux用が存在する。

njmonで収集した情報をInfluxDBにインプットすることで、Grafanaのコンソール画面でリアルタイムにグラフ表示できる。

Grafanaは、事前に設定した条件に合致した場合に通知する機能を備え、これを使用することでリソース使用状況の閾値監視とアラート通知が可能である。またGrafanaは、コンソール画面で期間を指定して過去の特定時点の情報を表示することもできる。

死活監視は、監視対象サーバーのping応答状況を監視する方法が一般的であるが、これはサーバーメトリクスを収集するエージェントであるTelegrafのpingプラグインを使用することで実現が可能である。

pingプラグインによりping応答結果を収集し、この結果をInfluxDBに収集、Grafanaでリアルタイム監視を実施する。

ただし、これらの構成を採用する場合、監視サーバーとしてInfluxDB、GrafanaおよびTelegrafが稼働するサーバーを用意せねばならない点に考慮が必要である。

監視サーバーの構成方法は、IBM Cloudの仮想サーバーを作成してこれらのソフトウェアを導入する方法や、IBM Cloudのカタログで用意されているInfluxDBやGrafanaのイメージを使用する方法が考えられる。

IBM Cloudのカタログイメージを使用する場合には、どちらもデプロイ先としてKubernetesなどのクラスタが必要となるので、追加費用や構築・運用の手間を考慮して監視サーバーの構成を検討する。

この実装例に登場した各コンポーネントについて、以下に簡単に紹介する。

njmon

・Power環境で使用可能な性能情報収集モジュール
・nmonと同等 (またはそれ以上) の統計情報と構成情報を収集可能
・nmonと同様、AIX用とLinux用が存在する
・収集したデータをInfluxDBやPrometheusといった時系列データベースやSplunkなどにアップロード可能

＜参考情報＞　njmon Project website

InfluxDB

・InfluxData社によって開発された、オープンソースの時系列データベース（Time Series DataBase）
・SQLに似た独自のInfluxQLという言語を利用することで、RDBのような使い方も可能

＜参考情報＞　InfluxDB Documentation

Grafana

・Grafana Labs社が開発したオープンソースのソフトウェアで、データ可視化のためのBIツール
・InfluxDBやPrometheus、 Elasticsearch、Splunk等に蓄積したデータをソースとして使用できる
・グラフを表示するダッシュボードは自由にカスタマイズ可能
・ダッシュボードはJSON形式で書き出し、公開されているテンプレートの使用も可能
・njmon用のテンプレートも複数公開されている
・事前に定義した条件に応じた通知が可能
・通知先はSlackやメールなど、さまざまな方法をサポートしている

＜参考情報＞　Grafana documentation

Telegraf

・InfluxData社によって提供されている、サーバーのメトリクスを収集してレポートするエージェント
・データの格納先はInfluxDB
・さまざまなメトリクスを取得するためのプラグインが存在し、設定ファイルで使用するプラグインを指定する
・pingプラグインを使用すると、対象サーバーのping応答の結果をDBに蓄積できる
・ping以外にも150以上のプラグインが用意されており、さまざまなソースからのメトリクス収集が可能
・CPU、メモリ、ディスク、カーネルなどの情報を取得できる
・syslog、tailなどログ転送に使用できるプラグインや、SNMP Trapプラグインが存在
・DB2、MySQL、Apacheなどの情報を取得するためのプラグインが存在
・プラグインの情報はTelegrafの公式ページやGitHubで公開されている

＜参考情報＞　
Telegraf Documentation　　
Telegraf Documentation プラグイン情報　　
GitHub Telegraf plugins　　

IBM CloudとPVSへリフト＆シフトしたシステムの監視概要

最後に、オンプレミス環境をIBM CloudとPVSへリフト＆シフトしたシステムの全体概要を、図表5にまとめた。

　
IBM Cloud 上のAPサーバーは、IBM Cloudの標準サービスであるIBM Cloud Monitoring、IBM Cloud Log AnalysisおよびIBM Cloud Activity Trackerを使用して、監視および監査証跡の取得を実施する。

このときAPサーバーには、メトリクス収集のためにIBM Cloud MonitoringおよびIBM Cloud Log Analysisのエージェントをそれぞれ導入する。

PVS上のDBサーバーは、IBM Cloud Monitoringが使用できないため、リソース監視と死活監視は代替のサービスを使用した監視の実装が必要である。

たとえばIBM Cloud上に監視サーバーを用意し、必要なソフトウェアを導入して使用する方法が考えられる。このとき、DBサーバーにはメトリクス収集のためにnjmonを導入する。

一方、プロセス監視やログ監視、監査証跡の取得は、IBM Cloudの標準サービスでAPサーバーとともに統合監視が可能である。

このように監視サーバーを用意する構成を選択する場合は、仮想サーバーの使用料金や仮想サーバーの維持管理作業が生じる点には注意が必要である。

また図表5では、IBM Cloud上のサーバーのリソース監視および死活監視はIBM Cloud Monitoringの使用を想定しているが、IBM Cloud 環境をTelegraf、InfluxDB、Grafanaといったオープンソースのソフトウェアで監視することも可能である。

その場合、IBM Cloud上のAPサーバーのリソース情報はTelegrafのプラグインで収集することになるだろう。

njmonとnmonで取得可能な項目を比較し、njmonを使用した場合に監視すべき項目名をまとめた情報や、各ソフトウェアの導入および設定方法、IBM Cloud標準サービスの設定方法など、実装に関する情報は以下に記載しているので参照されたい（なお、これらの資料はAIX 技術情報の「仮想化環境管理」のセクションにもリンクの記載がある）。

＜参考情報＞　
PowerVS監視ソリューション_202109.pptx　　
PowerVS監視ソリューション実装編.pptx　　
AIX 技術情報　　

本稿の内容が、オンプレミスのIBM Power環境のクラウド化やモダナイズを検討する際の参考となれば幸いである。