IBM Systems Director 実装のコツ
インストール、ディスカバリー、そしてトラブルシューティング
ここ数年間は幅広くIBM Systems Directorにかかわってきました。そしてIBM Systems Directorをうまく実装してIT環境を管理するためのいくつかのコツを見つけました。本稿ではそうしたコツを主に3つのカテゴリに分けてご紹介します。
- 実装のコツ ― Systems Directorをうまく実装するためのコツ
- ディスカバリー/アクセスのコツ ― エンドポイントを見つけてアクセスするためのコツ
- トラブルシューティングのコツ ― 問題を認識して修正するためのコツ
実装のコツ
まずは実装のコツをいくつかご紹介しましょう。
コツその1: 事前準備をして自社の環境を理解する。
IBM Systems Directorをインストールしようとする環境を理解するとIBM Systems Directorを確実にうまく実装するのに大いに役立ちます。ネットワーク環境とSystems Directorのネットワーク要件を明確にしておくことが重要です。Systems Director管理サーバーと管理対象のエンドポイント(管理エンドポイントということでMEPと呼びます)の間に正しいネットワーク・ポートをオープンしておかないとSystems Directorがエンドポイントを見つけることができないか、またはエンドポイントに対して特定の管理タスクを実行することができなくなります。IBM Systems Director Information Centerには必要となるポートが一覧になっていて便利なのですが、問題はすべてのポートが一覧されていることです。ここがまさに環境を理解しておくことが関係するところです。なぜなら必要となるポートは以下のようないくつかの要因に依存しているからです。
- 管理対象のエンドポイントのタイプ
- 通信対象のエージェントのタイプ
- 実行対象の管理アクティビティのタイプ
- Systems Directorのデータ・リポジトリとして使用されるデータベース
例として図１：必要なネットワーク・ポート のPower Systemsを管理するのに必要なネットワーク・ポートを考えてみましょう。ポート8421と8422はSystems Directorコンソール(ウェブ・ブラウザ)とSystems Directorサーバーとの間で必要となります(8421は非SSLウェブ・アクセス用であるのに対して8422はSSLアクセス用である点に注意してください)。ポート427(SLP)、22(SSH)、5988(CIM)、5989(CIM)はSystems Directorサーバーとハードウェア管理コンソール間の通信に必要となります。
ハードウェア管理コンソールをうまく見つけてアクセスすることは、ホスト(物理サーバーまたはフレーム)と仮想サーバー(LPAR)を明らかにすることでもあります。SSH、SLP、CIMの各ポートに加え、共通エージェントまたはCASポート(9510、9513、9514、9515)もSystems DirectorとOSのエンドポイントの間でエージェントの全機能を利用するために必要となります。
異なるエンドポイントでは、図にあるポートとは異なるポートが必要になる場合があることを覚えておいてください。たとえば、161ポート(AMMとのSNMPエージェント通信)や6090ポート(IBM Systems Directorサーバーと高度管理モジュール、管理モジュール、リモート・スーパーバイザ・アダプタ、リモート・スーパーバイザ・アダプタIIとの間の TCPコマンド・モード通信)はブレード・センターの管理に必要となります。同様にIBM iのエンドポイントに対するさまざまな管理活動では、IBM i DRDA/DDMサーバー・ジョブとのSSL通信用の448ポートやIBM iサーバー・ポート・マッパーとのSSL通信用の449ポートなどのようなさまざまなネットワーク・ポートが必要となります。
Systems Director管理サーバーとMEPとの間のネットワーク・ポートの可用性に加え、外部ウェブ・サイトへ最新情報を問い合わせたりダウンロードしたりするためにSystems Directorから外部ウェブ・サイトへアクセスすることも必要になります。これについてもInformation Centerに全リストが載っていますが、例としてSystems Director管理サーバーはサーバーのプロバイダー・サイト(eccgw01.boulder.ibm.com、eccgw02.rochester.ibm.com、www-945.ibm.com)やdownload3.bouler.ibm.comなどのダウンロード・サーバーにアクセスする必要があります。これについても全リストはInformation Centerをご覧ください。
コツその2: データベースのオプションとデータベースの考慮点を理解する。
Systems Directorはいくつかのデータベース管理システムをサポートしています。選択されたデータベースは、その大部分がMEPの数に基づいているデータベースのサイズ、組み込みデータベースを使用するのかSystems Directorで提供されているデータベース・クライアントを使用するのか(Systems Directorのバージョン6.3より前のバージョンでは組み込みデータベースはApache Derbyでしたが、バージョン6.3ではDB2となります)、データベースの場所(ローカルなのかリモートか)、データベース管理者のスキル・セット、などといったいくつかの考慮点に依存します。Systems Directorバージョン6.3の選択肢を表1に示します。
デフォルトのデータベースであるDB2はSystems Directorに同梱されているということを覚えておいてください。 DB2を使用すると、データベース・インスタンスと構造の設定および構成がSystems Directorのインストール手続きの中に直接組み込まれているので、 Systems Directorのインストールが簡素化されます。ほとんどの実装においては組み込みデータベースが選択されます。関連するコツとして覚えておいていただきたいのは管理データベースがインストールされるロケーション(この場合ファイル・システムのこと)です。Systems Directorのデフォルトのインストールでは管理DB2は\home\dirinst1ディレクトリにインストールされます。パフォーマンスを考慮すると\home\dirinst1ディレクトリをSystems Director自体(\opt\ibm\directorにインストールされている)のファイル・システムとは別のファイル・システムにしておくと良いでしょう。
コツその3: Systems Director管理サーバーの要件が確実に満たされるようにする。
Systems Director管理サーバーのインストール先であるプラットフォーム(AIX、Linux、またはWindows)が前提条件を満たすことで、インストール・プロセス中でのエラーやいらいらを避けるのに役に立ちます。インストール前要件チェッカーはメモリ、スワップ空間、ファイル・システムの空き空間、ファイル許可、ソフトウェア・パッケージのインストール、ネットワーク・ポートの可用性などといったいくつかのプラットフォーム要件をチェックするもので、Systems Directorのウェブ・サイトで利用可能です。インストール前要件チェッカーはSystems DirectorダウンロードのISO版でも利用可能であることにご注意ください。さらに、サーバーの適切なサイジング用に負荷評価機能へのリンクも利用可能です。
コツその4： 適切な人的資源の入手が重要。
Systems Directorの実装を成功させるためのカギを握る要因の1つが適切な資源を入手することですが、特にこの場合は人的資源のことを指しています。たとえば、組み込み/デフォルトのデータベースを使用しない場合はデータベース・インスタンスの作成とそのインスタンスへのアクセスの構成を管理するデータベース管理者を確保する必要があるでしょう。ネットワーク管理者を確保することも、必要となるネットワーク・ポートをオープンにしてアップデート・マネージャ用のフィックス・セントラルへのアクセスを構成できるようにするために重要です。MEP管理者を確保してアクセス機能用のユーザーの資格認定を取得することも必要になるでしょう。Systems DirectorがActive DirectoryまたはLDAPに統合されている場合は、Systems Directorのセキュリティ・プロパティ・ファイルの設定を構成してSystems Directorグループを集中化されたセキュリティ格納場所に作成するために管理者を確保することが必要となります。
コツその5: Systems Directorを最新のバージョンにアップデートする。
インストール後に最初に実行しなければならないタスクの1つが、Systems Directorを利用可能な最新のリリース・コードにアップデートすることです。アップデートはアップデート・マネージャで行います。Systems Directorの比較的新しいバージョンには通常新しい機能と欠陥の解決が含まれています。アップデート機能を実行すると、Systems Directorがインストールされている環境が外部へのネットワーク・アクセスに対して適切に構成されているかどうかも検証してくれます。
Systems Directorを新しい環境にインストールするとき、私は以下の手順で実行します。
- Systems Directorのインストール
- エージェント・マネージャの構成
- Systems Directorの起動
- Systems Directorのエンドポイントの棚卸し
- Systems Directorのアップデート
- Systems Directorの再起動
Systems Directorの実装がデフォルト以外のデータベースを使用している場合は、Systems Directorをインストールしてアップデートし、次にSystems Directorを新しいデータベースに対して構成します。これによりデータベースの接続を構成する前にSystems Directorの基本的なインストールと機能を検証することができます。
ディスカバリーとアクセスのコツ
Systems Directorの主要な機能の1つであり、繰り返し実行される機能がエンドポイントのディスカバリーとSystems Directorからのアクセスの構成です。以下のコツはSystems Directorのアーキテクチャ、エンドポイントを管理するためのエージェントの役割、Systems Directorに対してエンドポイントを一意に識別することの重要性について説明したものです。
コツその6: アーキテクチャを理解する。
ディスカバリーとアクセスについてはSystems Directorのアーキテクチャをよく理解しておくことが必要です。図1に示したアーキテクチャをもう一度見てみましょう。Systems Directorが実際には管理サーバー上にいくつかのコンポーネントをインストールしている点に注意してください。このコンポーネントは図1中のSystems Directorサーバーのボックス中に描かれています。Directorサーバーは管理サーバーのコード、ロジック、または機能を表現しています。CIMサーバーは共通情報モデル(Common Information Model)で、Systems Directorとプラットフォーム・エージェントの間の通信を処理します(CIMとCASエージェントもまた管理サーバー上にインストールされていなければインストールされる点にお気づきでしょうか)。エージェント・マネージャはエンドポイント上の共通エージェントに対する通信を処理します。デフォルトではデータベース・サーバーは管理サーバー上にインストールされ、Systems Directorもエージェント・マネージャもデータベース・サーバー上にデータベース構造を持ちます(バージョン6.3ではエージェント・マネージャは引き続きApache Derbyをデータベースとして使用していますので、実際には2つの異なるデータベース・サーバーがSystems Directorサーバー上にインストールされているという点に注意してください)。さらに、管理サーバー上の軽量インタフェース(LWI: Light Weight Interface)が管理コンソール(ウェブ・ブラウザ)からのウェブ・リクエストを処理し、そのリクエストを適切なDirectorサーバー・コードに転送します。
コツその7: エージェントの役割を理解する。
Systems Directorはその管理機能を、対象とするエンドポイント上のエージェントを介してエンドポイント上で実行します。エージェントはそれぞれ異なる通信プロトコルを代表しており、3つの異なるレベルのエージェントがあります。レベル0のエージェントはAIX上のSSH、Linux、IBM i、Windows上のDCOMMなどといったOSに固有なプロトコルにすぎません。レベル0のエージェントでエンドポイントを管理することはエージェントレス管理と呼ばれることがあります。レベル１のエージェントはプラットフォーム・エージェントでCIMプロトコルと呼ばれることがあり、レベル2のエージェントは共通エージェントでCASプロトコルと呼ばれることがあります。共通エージェントとプラットフォーム・エージェントは、エージェントレス管理に加えて高度管理機能、インベントリ、自動機能等といった追加の機能を提供します。MEP上にインストールされているエージェントのレベルを表2に示します。
コツその8: エンドポイントが一意であることを確実にする。
Systems Directorはいくつかのシステム属性を使用してエンドポイントを識別します。その属性のうち2つはsshキーとTivoli IDです。AIXのエンドポイントのディスカバリーに共通している問題はこれらの属性が一意ではないということです。これはAIXのインスタンスがNIMサーバーからのmksysbイメージで作成され、インスタンスを運用環境におく前にキーがリセットされていない場合に発生します。このキーは以下のコマンドでチェックできます。
2つ以上のエンドポイントで重複したsshキーが見つかった場合はそのキーをリセットする必要があります。AIXシステムについては、図2に示したコマンドでこのキーをリセットします。
IBM iでは\QOpenSys\QIBM\Userdata\SC1\OpenSSH\openssh-2.8.1p1.etcディレクトリにある既存のキーを削除することでsshキーを再生成することができます。IBM i上でssh処理が開始された時にこのキーがこのディレクトリ中にない場合は、自動的に再生成されます。キャッシュにあるこのキーに依存するシステムやアプリケーションはどれもキーを再キャッシュする必要があることを覚えておいてください。
コツその9: エンドポイントは1つのエージェント・マネージャのみに知らせることができる。
Systems Directorのコンポーネントに加えてエージェント・マネージャのコンポーネントもインストールされます。エージェント・マネージャは共通エージェントの証明書を保存し、Systems Directorが正常に機能するための重要なマネージャです。デフォルトの構成はSystems Directorと一緒にインストールされたエージェント・マネージャを使用するようになっていますが、リモート・エージェント・マネージャを使用することもできます。ここで重要なのは、エンドポイントは1つのSystems Directorサーバーによってしか管理できず、１つのエージェント・マネージャにしか登録できないということです。他のエージェント・マネージャにすでに登録されているエンドポイントへのアクセスを取得しようとするとアクセス状態が「Failed」になります。これはSystems Directorとエージェント・マネージャが再インストールされた時に共通して起こります。
既に登録されているエンドポイントを管理するには、そのエンドポイント上で以下のコマンドを実行してそのエンドポイントを「非管理」状態と呼ばれる状態にする必要があります。
このコマンドは、エージェントの登録情報をそのエンドポイントから削除しますので、Systems Director中のリクエスト・アクセス機能を介して新しいエージェント・マネージャで登録することができます。
コツその10: 適切な名前解決が必要。
Systems Directorはネットワークに負荷をかけるアプリケーションです。つまり、ネットワーク上のエンドポイントと通信する機能が必要であるということです。Systems Directorは管理サーバーがインストールされているシステムのネットワーク解決に依存しています。たとえば、Systems Directorがネットワーク名の解決にローカルの定義を使用しているAIXシステム上にインストールされている場合、Systems Directorもそのローカルの定義を使用します。同様に、システムがドメイン名前システム(DNS: Domain Name System)を使用している場合、これは通常の構成ですが、この場合はSystems Directorも名前解決にそのDNSに依存することになります。Systems Directorがシステム名からIPアドレス、またはIPアドレスからシステム名への解決に問題を生じている場合は、OSレベルでいくつかツールが用意されていますのでそれを使用して適切な名前解決を検証することができます。
そうしたツールの1つで優れたツールにnslookupがあります。このコマンドはOSの名前解決設定を使用して、指定された名前からIPアドレスへ解決しようとします。たとえば、
は指定された名前のIPアドレスを返すはずです。IPアドレスから名前への逆方向の解決も検証しておくことが重要です。nslookupでは名前の代わりにIPアドレスを指定すればこの検証を行えます。
コツその11: アクセス失敗のメッセージを信用しない。
あるエンドポイントへのアクセス要求が失敗に終わったとSystems Directorが誤ってレポートしてくることがあります。私はこれを2つの異なる状況下で見たことがあります。1つ目の状況は単純にタイミングの問題で、しばらくしたらステータスは正しく「OK」にアップデートされました。2つ目の状況は、プロトコルの1つへのアクセスが上手くいっているのにもう1つのプロトコルへのアクセスが失敗した時に誤ってアクセスが失敗したとレポートしてきたものです。例として、共通エージェントとプラットフォーム・エージェントがインストールされていて、SSHがAIXのあるエンドポイント上で有効になっているとき、そのエンドポイントに対しては最大で4つのプロトコルが見つかります。
- シンプル・ネットワーク管理プロトコル(SNMP: Simple Network Management Protocol)
- セキュア・シェル(SSH: Secure Shell)
- 共通情報管理(CIM: Common Information Management)
- プラットフォーム・エージェント(CAS)
SNMPプロトコルはお知らせのみのプロトコルですからアクセス・ステータスは常にOKとなります。SSH、CIM、CASの各プロトコルでうまくアクセスするには一般的にはシステム管理特権(AIXとLinuxではroot、IBM iではqsecofr、Windowsでは管理者)を必要とします。ここが面白いところです。CIMプロトコルとCASプロトコルへのアクセスはSystems Directorサーバーからの要求アクセス機能を介してか、またはconfigure.sh機能を介してMEPからのいずれかで発生します。Systems Directorサーバーからのアクセス要求は3つのすべてのプロトコル(SSH、CAS、CIM)へのアクセスを取得しようとしますが、エンドポイントからの登録はCASプロトコルとCIMプロトコルだけを登録します。これにより、一部のプロトコルはアクセスができない状況になります。各プロトコルのアクセス状況を判断する1つの方法は[セキュリティ]-[アクセスの構成]機能を介するもので、図3に示した通り、対象のエンドポイント用に発見したすべてのプロトコルを表示します。
今から使用しようとしているプロトコルが「OK」状態であれば、その他のいくつかのプロトコルが「Failed」や「No Access」という状態を示していたとしても大丈夫だということを覚えておいてください。「OK」アクセスとなっているもっとも上位のレベルのプロトコルがSystems Directorが管理機能用に使用するプロトコルとなります。
トラブルシューティングのコツ
コツその12: Systems Directorのデータをバックアップする。
Systems Directorのデータを定期的にバックアップしておくことは良いことです。データのバックアップはsmsaveコマンドで行います(データベースをバックアップする前にSystems Directorをシャットダウンしておかなければなりません)。Systems Directorに同梱されているデータベース用管理DB2を使用したSystems Directorのデフォルトのインストールでは、データベースのバックアップは\opt\ibm\director\backupディレクトリ中に、サブディレクトリ名にバックアップが実行された日付と時刻が付いて格納されます。smsaveコマンドはデータを回復するのにも使用できます。
もう1つ知っておいていただきたいコマンドがsmrsetコマンドで、これはデータをインストール状態にリセットします(つまり、Systems Directorが認識しているデータはSystems Directorがインストールされているエンドポイントになるだけです)。
コツその13: 情報とヘルプを入手する。
Systems Directorに関する豊富な情報が入手可能です。Systems Directorのソフトウェアのページからご覧になるのがよいと思います。ここには管理サーバー、エージェント、プラグインなどへのリンクの他に、サイジング・ツールや製品のドキュメントへのリンクもあります。Systems Director Information Centerには通常最新の情報が掲載されています。
コツその14: エージェント・マネージャ・データベースを管理する。
Systems Directorで作業する際に覚えておいて欲しい重要なアーキテクチャの項目の1つにエージェント・マネージャがあります。エージェント・マネージャは共通エージェントからの証明書を管理し、実際にはSystems Director自体とは別のコンポーネントです(Systems Directorのデフォルトのインストールではエージェント・マネージャのローカルコピーもインストールされます)。Systems Director管理サーバーは1つのエージェント・マネージャに対してのみ構成することができます。ただし、そのエージェント・マネージャはローカル(デフォルト)でもリモートでもかまいません。覚えておかなければいけない重要なことは、エンドポイントの削除などといったSystems Directorでのアクションはエージェント・マネージャに保存されているデータ(証明書)にはまったく影響をおよぼさないということです。これからお話しするトラブルシューティングのコツをご理解いただくには、エージェント・マネージャの役割をご理解いただく必要があります。
まず、ディスカバリー機能とアクセス機能についてみてみましょう。CASプロトコルで発見されたエンドポイントに対してSystems Directorからアクセス要求が来たときは、そのアクセス要求はエージェント・マネージャによって実行され、返された証明書は(Systems Directorのデータベースとは別の)エージェント・マネージャのデータベース中に保存されます。Systems Directorがあるエンドポイントに対してCASプロトコルで機能を実行しようとしたとき、そのアクセスのための証明書もエージェント・マネージャから入手します。
トラブルシューティングの観点から見ると、覚えておかなければいけない最も重要なことは両データベース(Systems Directorとエージェント・マネージャ)とも維持しなければならないということです。知っておかなければならないコマンドがいくつかあります。そしてそのコマンドはすべてSystems Director管理サーバーの\opt\bin\director\lwi\runtime\agentmanager\toolkit\bin ディレクトリにあります。
最初のコマンドは証明書情報の一覧を表示します。
このコマンドで<ampassword>はSystems Directorのインストールの一部(具体的にはconfigAgtMgr.shスクリプトが実行されたとき)で定義されたエージェント・マネージャの管理パスワードを指します。 各々の共通エージェントのエンドポイントにおいて、図4に示したレコードが出力されます。
証明書をエージェント・マネージャのデータベースから削除しなければならない場合があります。これは通常、SSHキーを持つエンドポイントが他のエンドポイントのSSHキーと重複しているなど、重複したエンドポイントが見つかった時です。(重複したSSHキーの対処方法についてはSystems Directorの使用のコツに関する記事で近々触れたいと思います。エンドポイントの証明書の削除は2段階のプロセスですが、両手順ともRetrieveAgents.shコマンドの「ManagedElement I」出力に依存します。
LogicallyDeleteAgents.shコマンドで 証明書を論理的に削除する最初の手順は次の通りです。
2番目の手順は次のようにPurgeAgents.shコマンドで証明書情報を削除します。
まず計画をたててから使用する
適切な計画を立てることはSystems Directorの実装を上手く行うために重要であり、システム管理ソフトウェアを皆さんの部門で稼働するのに本稿がお役にたてればと思います。Systems Directorを使用してIT環境を管理する上で私が紹介したコツをカバーするPOWER IT Proの今後の記事に着目してください。
