1. 千手システム導入にあたって

この章では、運用管理システムSenju DevOperation Conductorについて説明します。

1.1. 千手システムとは

1.1.1. 統合運用管理システム「Senju DevOperation Conductor」

統合運用管理システム「Senju DevOperation Conductor」は、LAN、およびWANで接続された、UNIX、Windows、Linuxサーバーで構成された分散環境における業務システムの運用管理を、運用管理サーバーから一元的に行うためのシステムです。

_images/product_image.jpg

図 1.1 Senju DevOperation Conductorの運用管理イメージ

  • GUI画面による簡単な操作

    千手システムの操作は、Windows上の全機能統一されたインターフェースのGUI画面から行います。そのため、UNIX/Linuxの環境に不慣れなオペレータでも、簡単に運用操作を行えます。

  • 複数コンソールによる分業体制

    複数の運用管理コンソールからシステムを管理できます。複数の運用管理コンソールを設置することで、システム管理者(管理対象の登録、変更作業などの担当者)と、運用オペレータ(運用操作、監視の担当者)の分業を意識した運用が可能になります。

  • 千手マネージャからの統合運用管理

    1台の千手マネージャからネットワーク上で稼働する複数の業務システムのサーバー群に対する運用管理が可能です。分散環境を千手マネージャから集中的に管理を行う事で、管理者の作業負荷を軽減できます。

  • 多角的視点の運用管理

    マルチエージェント機能を用いることにより、1台のサーバー上に複数の千手エージェント機能を独立して稼働させることができます。業務システム毎、部門毎に視点を変えた運用管理が可能になります。

  • 各サーバーの監視および運用

    千手エージェント、および千手センサーとして登録したサーバーの稼働状況やリソースの監視、ジョブの実行ができます。

  • 異機種/OS、マルチベンダーへの対応

    主要なベンダーのUNIX/Linux、Windowsをサポートしています。異機種混在環境にも導入が可能です。また、将来的に機器の増設を検討する場合にも、ベンダーの制約をうけません。

  • エージェントレスな監視を実現

    千手センサーは、エージェントソフトを導入することなく、統合的なシステム監視を実現するSenju DevOperation Conductorのオプション機能です。対象サーバーへのエージェントソフトのインストールが不要であるため、稼働中のアプリケーションへ影響を与えることなく、大規模なシステムでもスムーズに導入することが可能です。

  • 構成情報の収集による構成管理

    千手エージェント、および千手センサーとして登録したサーバーの構成情報を定期的に取得することができます。これにより、サーバーの構成管理や変更の有無を確認することができます。

  • システムのリレーション管理

    システムを構成するIT機器やサービスを定義し、これらシステムを構成するアイテムの関係性を設定することで、システム全体の構成情報を一元的に管理することが可能です。これにより障害が発生した際に障害の発生個所や影響範囲の特定を速やかに行うことができ、迅速に障害に対応することが可能です。

  • システム維持管理部門への情報公開

    システムの稼働情報をWEBブラウザを通じてシステム維持管理部門に公開することができます。これにより、システム維持管理担当者がシステム障害を調査する際に遠隔地から迅速に調査を行うことが可能になります。

1.1.2. 「Senju DevOperation Conductor」を構成するサブシステム

千手システムは、共通機能と、機能目的に応じた5つのサブシステム(イベント/モニタリング/ジョブスケジュール/キャパシティ/コンフィグレーション)から構成されます。各サブシステム単位で必要に応じた導入が可能であり、さらに各サブシステム内で細かく設定されたエクステンション機能から、必要となる機能のみを選択して導入することが可能です。また、これらの機能追加はライセンスの入替のみで行うことができるので、容易に機能を拡張することができます。

_images/subsystems.jpg

図 1.2 Senju DevOperation Conductorを構成するサブシステム

1.1.3. Senju DevOperation Conductorによる運用管理の基本構成

千手システムの基本構成について説明します。

  • 千手ドメイン

    1台の千手マネージャが管理する範囲を千手ドメインと呼びます。千手システムでは、1台の運用管理サーバー(千手マネージャ)と、その運用管理サーバーに管理される管理対象ノード群(千手エージェント、千手センサー)を1つの千手ドメインとして扱います。

1.1.3.1. システムを構成するノード

千手システムは、次の7種類のノードによって構成されます。

1.1.3.1.1. 千手ブラウザ(運用管理コンソール)

千手マネージャに接続し、システム管理者や運用オペレータが千手システムの運用、監視、管理などの操作を行うことができます。

運用管理コンソールは単に千手ブラウザと呼ぶことがあります。システム管理者と運用オペレータがそれぞれ業務を行う場合に、異なるマシンで稼働する千手ブラウザを複数設置することができます。

また、千手ブラウザからは、最大3台の千手マネージャに接続することができます。

注釈

  • 1台の千手マネージャに同時に接続可能な千手ブラウザの数は、7つまでです。

1.1.3.1.2. 千手オフライザ

千手マネージャに接続せずに、モニタリング、ジョブスケジュールや千手エージェント定義を登録することできます。

1.1.3.1.3. 千手マネージャ(運用管理サーバー)

千手ドメイン全体を管理し、千手システムが稼働するために必要となる情報が一元的に保持されているノードです。

千手システムを導入する際に、千手マネージャとするノードを1台決めておきます。

1.1.3.1.4. 千手エージェント(管理対象ノード)

千手マネージャから管理され、モニタリングやジョブを実施するノードです。また、プローブノード、SNMPコレクタ、千手構成ファイルサーバーとして設定することが可能です。

1.1.3.1.5. 千手データベースサーバー

千手システムが収集したモニタリングやジョブの履歴データなどを蓄積、管理するサーバーです。キャパシティ、ジョブレポート、ジョブアクティビティ機能で利用します。また、千手ウェブサーバーをインストールするとき必要です。

注釈

  • 1つの千手ドメインに設置できる千手データベースサーバーは1台までです。

1.1.3.1.6. 千手ウェブサーバー(千手DevOpsポータル)

千手データベースサーバーと同じノードにインストールされ、千手DevOpsポータル機能として、WEBコンソールからの接続機能を提供するサーバーです。

注釈

  • 千手ウェブサーバー(千手DevOpsポータル)は千手データベースサーバーを必要とします。

  • 1つの千手ドメインに設置できる千手ウェブサーバーは2台までです。

1.1.3.1.7. 千手DevOpsポータル

WEBコンソールからの千手システムの操作・参照する機能を提供するサーバーです。また、複数の千手ドメインの情報を1台の千手DevOpsポータルで管理することができます。

1.1.3.1.8. 千手センサー
千手センサーは、千手システムのパッケージをインストールせずに管理対象となるノードです。プローブノードとして指定した千手マネージャまたは千手エージェントからモニタリングやジョブを実施します。

ノードにより、千手センサー(サーバー)、千手センサー(ネットワーク)、千手センサー(カスタム) のいずれかで登録します。

1.1.3.1.9. WEBコンソール

Webブラウザを使用して、千手ドメインの管理項目の参照や日々蓄積される千手稼働状況の参照を行う機能です。

1.1.3.1.10. 千手構成ファイルサーバー

千手マネージャのログファイル(メッセージログ、オペレーションログ、統計データ)及び、コンフィグレーションサブシステムによって取得された千手構成管理項目/構成管理項目の収集ファイルの情報が一元的に蓄積されている千手エージェントノードです。

注釈

1つの千手ドメインにつき、設置できる構成ファイルサーバーは1台です。

1.1.3.1.11. SNMPコレクタ

SNMPエージェントからのSNMPトラップを受信するノードです。

1.1.3.1.12. マルチエージェント

マルチエージェントは、1台のマシンに複数の千手エージェントを構築することを可能にした機能です。1台のデフォルトエージェントと複数のサブエージェントで構成されます。この機能により、インストールした千手エージェントは個別の運用管理サーバーで管理することが可能です。

1.1.3.1.13. プローブノード

千手センサーでモニタリングやジョブを実施するノードです。千手センサーに、千手マネージャまたは千手エージェントをプローブノードとして指定します。

1.1.3.2. システムの構成例

千手システムの構成例を以下に示します。

  • 1台のコンソール設置する場合 (1)

  • 複数のコンソールを設置する場合 (2)

  • WEBコンソールを設置する場合 (3)

  • 千手ブラウザにより複数のドメインを一ヶ所から運用する場合 (4)

  • 千手構成ファイルサーバーを設置する場合 (5)

  1. 1台のコンソールを使用する場合
    _images/image018.jpg

    図 1.3 1台のコンソールを設置する場合

    この例は、もっとも簡単な構成で、小規模なシステム (管理対象ノードが数台程度) で、監視業務を中心とする場合に適しています。

  2. 複数のコンソールを使用する場合
    _images/image020.jpg

    図 1.4 複数のコンソールを設置する場合

    この例では、2台のコンソールから千手システムを使用しています。この場合、運用管理に必要なノードは2台になります。システム管理者と運用オペレータによる分業体制をとり、両者が異なるノードを使って作業を行う場合に、複数台のコンソールを設置する必要があります。

    中・大規模なシステムで、監視業務、およびジョブスケジュールの運用管理を行う場合に適しています。

  3. WEBコンソールを使用する場合
    _images/image019.jpg

    図 1.5 WEBコンソールを設置する場合

    この例では、 1. で示したドメインと同様の構成に、千手ウェブサーバーおよび千手データベースサーバーを設置することによって、WEBコンソールが使用できるようにした場合を示しています。千手ブラウザで管理情報の登録・運用操作を行い、WEBコンソールからは管理情報の閲覧・操作を行います。

    WEBコンソールはWebブラウザを利用できる端末であればどこからでも使用できますので、遠隔地からの操作を行う場合に適しています。

  4. 統合コンソールを使用する場合 (複数のドメインを管理する場合 )
    _images/image024.jpg

    図 1.6 複数のドメインを管理する場合

    この例では、 2. で示したドメインと同様の構成の複数ドメインを、1つの千手ブラウザで統合的に管理しています。

    複数の拠点・支社・工場などで部門単位に運用・監視を行い、かつ全体の監視や運用支援を本社機構の情報システム部門で一括して行う場合に適しています。

  5. 千手構成ファイルサーバーを使用する場合
    _images/image017.jpg

    図 1.7 千手構成ファイルサーバーを設置する場合

    この例では、 1. で示したドメインと同様の構成に、千手構成ファイルサーバーを設置し、WEBコンソールを使用するようにした場合を示しています。

    千手ブラウザでコンフィグレーションの登録・運用操作を行い、WEBコンソールからは取得したコンフィグレーション情報のダウンロード・閲覧を行います。

1.1.4. Senju DevOperation Conductorライセンスについて

1.1.4.1. Senju DevOperation Conductorライセンス体系

千手システムでは、各サブシステムの利用に必要不可欠なベース機能と、ユーザーが必要に応じてベース機能にアドオンできるエクステンション機能を分けることによって、運用面およびコスト面において柔軟なライセンス体系を用意しています。

  • イベント/モニタリング/コンフィグレーション

    [BASE]

    • メッセージの一元管理

    • メッセージに対する自動アクション

    • システム情報監視

    • ディスク容量監視

    • プロセス稼働状況監視

    • システム詳細情報監視

    • カスタム監視

    • パケット監視

    • SNMP監視

    • ログ監視

    • 構成情報の蓄積

    • 千手構成管理項目の蓄積

    • ファイル情報の取得

    • ファイルリスト情報取得

    • コマンド実行による情報の蓄積

    • SNMP項目の蓄積

    • WMI情報の蓄積

    • レジストリ情報の蓄積

    • イベントログ情報の蓄積

    • 変更検出

    [EXTENSION]

    • ランブックオートメーション(自動手順書実行、千手オートスケール機能)

    • WEB-Standard監視

    • Apache監視

    • IIS監視

    • Oracle監視

    • SQL Server監視

    • DB2 UDB監視

    • PostgreSQL監視

    • Mail-Standard監視

    • WebLogic監視

    • WebSphere監視

    • JBoss監視

    • .NET Framework監視

    • VMware監視

    • Hyper-V監視

    • トラップ収集

    • AWS監視

    • WEBコンソール

    • CCMS Monitoring for mySAP

    • Azure監視

  • ジョブスケジュール

    [BASE]

    • カレンダーによる計画運用

    • ジョブ/ネット/フレームの稼働状況表示

    • ジョブ/ネットの実行順序制御

    • 実行中ジョブ/ネット/フレームに対する操作

    • ジョブ/ネット/フレームの検索

    • ロードバランス(負荷分散)機能

    • 複数ノードでの同一ジョブ実行機能

    • 同一ジョブの繰り返し実行

    • 条件分岐によるジョブ制御

    • ジョブサービス機能

    [EXTENSION]

    • セカンダリマネージャ

    • ジョブ定義数拡張

    • ジョブマネージャ連携

    • ジョブレポート

    • ジョブアクティビティ(ジョブレポート[EXTENSION]を利用)

    • Job Scheduler for R/3

  • キャパシティ

    [BASE]

    • 稼働統計データ蓄積

    • グラフ表示

    • 蓄積データ出力

    [EXTENSION]

    (なし)

1.1.4.2. 千手システムライセンス

千手システムでは、様々な監視・運用項目を定義、操作するために、ライセンスが必要となります。ライセンスはSenju DevOperation Conductor導入時に設定しますが、使用サブシステムやエクステンションの追加、有効期限の延長の際には、ライセンスの更新が必要となります。

1.1.4.2.1. ライセンスキー

千手システムの購入内容によって、使用可能なサブシステム、機能、有効期限は異なります。そして、これらを設定するのがライセンスキーです。設定内容の参照や変更は、千手ブラウザより、ドメインのプロパティを開いて行います。詳細は、 ライセンスキーの変更 を参照して下さい。

1.1.4.2.2. ライセンスによる使用制限

ライセンスキーによって以下のような使用制限がかかります。

  • 千手ブラウザライセンス

    千手ブラウザライセンスは、千手マネージャに同時に接続する千手ブラウザの数だけ必要です。

    千手ブラウザライセンスがない場合、千手ブラウザから千手マネージャへの接続が行えません。

  • WEBコンソールライセンス

    WEBコンソールをご使用になる場合は、別途WEBコンソールライセンスが必要になります。

    WEBコンソールライセンスがない場合、WEBコンソールからの操作・参照機能が使用できません。

  • モニタリングライセンス

    モニタリングライセンスは、管理対象となるノード数だけ必要となります。

    モニタリングライセンスが無い場合、もしくは、ライセンス数を超えるノードの定義を行った場合、モニタリングの機能が使用できません。

  • ジョブスケジュールライセンス

    ジョブスケジュールのライセンスが無い場合、ジョブスケジュールの機能が使用できません。

  • キャパシティライセンス

    キャパシティのライセンスが無い場合、キャパシティの機能が使用できません。

  • エクステンションライセンス

    各エクステンションのライセンスが無い場合、各エクステンションの機能が使用できません。

    ただし、モニタリングサブシステムのエクステンションは、ライセンスが無いエクステンションについても監視タスクが表示され、1エージェントだけ設定・評価できるようになっています。新しい用途のサーバー追加時などの評価時に一時的にトライアルとしてご利用いただけます。

    ライセンスが無いエクステンションの監視タスクを設定している場合は、毎日午前9:00、あるいはブラウザを起動してマネージャにログインした時に警告ダイアログが表示されます。

    千手ブラウザオプションにより、ライセンスが無いエクステンションについては監視タスクを表示しないようにすることも可能です。

    千手ブラウザオプションについては 千手ブラウザオプション一覧 を参照してください。

1.1.4.2.3. ライセンスの有効期限

ライセンスには有効期限があり、それを超えるとシステムが利用できなくなります。有効期限は、千手ブラウザより、ドメインのプロパティから参照できます。詳しくは、 Senju DevOperation Conductorライセンスキーについて を参照して下さい。

また、ライセンスの期限が残り1か月となると、千手ブラウザに事前に警告ダイアログが表示されます。

1.1.4.2.4. ライセンスキーの変更方法

ライセンスキーの変更は、千手ブラウザ、または、コマンドプロンプトから行います。詳しくは、 千手ブラウザからのライセンスキーの変更 、または、 コマンドラインからのライセンスキーの変更 を参照して下さい。また、ライセンスの変更が反映されるタイミングは変更内容によって異なります。

  • ライセンスの有効期限を延長した場合、反映は直ちに行われます。
    期限が切れた場合、千手ブラウザは接続できなくなりますが、モニタリングシステムやジョブスケジュールシステムは稼働します。

    なお、ライセンスキーはコマンドから登録して下さい。詳しくは、 コマンドラインからのライセンスキーの変更 を参照して下さい。

  • ライセンス数を追加/削減した場合、反映は直ちに行われます。

    ライセンス数を削除するライセンスキーに変更する際は、ライセンスに関連する定義登録を千手ブラウザから削除してからライセンスキーを変更して下さい。

  • サブシステムを追加/削除した場合、千手マネージャおよび、当該機能を用いる千手エージェントへ[反映(監視属性)]および千手システム再起動 ( リブート ) を行って下さい。

    サブシステムを削除するライセンスキーに変更する際は、サブシステムに関連する定義登録を千手ブラウザから削除してからライセンスキーを変更して下さい。

  • エクステンション機能ライセンスを追加/削減した場合、ランブックオートメーションライセンス、ジョブレポートライセンス、SNMPコレクタライセンスに関しては、千手マネージャおよび、当該機能を用いる千手エージェントへ[反映(監視属性)]および千手システム再起動 ( リブート ) を行って下さい。

    ライセンスを削除するライセンスキーに変更する際は、ライセンスに関連する定義登録を千手ブラウザから削除してからライセンスキーを変更して下さい。

  • 千手ウェブサーバーライセンス、SNMPコレクタライセンスに関しては、ライセンスの有効期限を延長した場合は、当該機能を用いる千手エージェントへの [反映(監視属性)]操作を行って下さい。

注釈

  • 複数の千手ブラウザを使用している場合、ライセンスキーの変更は1台の千手ブラウザから行って下さい。なお、他方の千手ブラウザへライセンスの内容を反映するには、ライセンスキーの変更を行っていない側の千手ブラウザで下記のいずれかの操作を行って下さい。
    • ドメインのプロパティ画面を開き閉じる。

    • 千手ブラウザを再接続する。

  • WEBコンソールを使用している場合、ライセンスキーの変更後に千手ウェブサーバーのサービス(Senju Extended Interface Service_千手稼働アカウント)を再起動してください。

1.2. 千手システム導入の前に

ここでは、千手システムを導入するにあたって、検討しておく事柄について説明します。

1.2.1. 管理範囲

千手システムを導入するにあたって、業務システムの管理範囲を明確にするために、次のことを考慮しておく必要があります。

1.2.1.1. 管理対象ネットワーク

千手システムは、IPプロトコルで接続されたネットワーク上のノードを対象にしています。この中の、管理するIPネットワークの範囲を決定します。通常は、ネットワーク番号で管理ネットワークを定義します。

1.2.1.2. 管理対象機器

管理する機器は、IP接続されたUNIX、Linux、Windows機です。モニタリングサブシステムのネットワーク監視機能により、その他のネットワーク機器( ルータなど ) を監視することも可能です。

1.2.1.3. 管理項目

管理対象システムに対して管理する項目 (アプリケーション、ジョブ等 )を決定します。管理する項目は、利用する機能 (サブシステム)によって異なります。また、管理対象が多い場合は、予め名前付けのルールを決めておくとよいでしょう。たたし、次の項目については、業務システム内でのネーミングを一意につけるようにして下さい。

  • 千手システム共通機能関連
    • ノード名

    • ノードグループ名

    • ユーザー名

    • 営業日カレンダー名

    • 週間スケジュール名

    • コマンド名

    • パラメータ名

    • アイテムグループ名

    • アイテム名

    • リレーション名

    • ネーミングフィルタ名

  • イベント関連
    • メッセージID

    • メッセージフィルタ名 (各ドメインのマネージャが送るメッセージをフィルタリングする)

    • ルールグループID

    • ルールID

    • メールテンプレート名

    • メール連絡先名

    • 連絡先グループ名

    • テンプレートグループ名

    • セクション名

    • ブックグループ名

    • ブック名

  • モニタリング関連
    • カスタム監視項目カテゴリ名

    • カスタム監視項目名

    • 監視タスク名

    • ログファイル監視定義(ログフィルタ)名

    • イベントログ監視定義(イベントログフィルタ)名

  • ジョブスケジュール関連
    • 稼働日カレンダー名

    • システム名

    • フレーム名

    • ネット名

    • ジョブ名(分岐ジョブ名)

    • 動作環境名

    • 動作環境プール名

    • トリガ名

    • リソース名

    • ジョブサービスチェック項目名

    • ジョブサービスグループ名

    • ジョブレポート名

  • キャパシティ関連
    • グラフ名

  • コンフィグレーション関連
    • 接続設定名

    • 構成管理項目カテゴリ名

    • 構成管理項目名

    • 実行ユニットグループ名

    • 実行ユニット名

    • 履歴表示設定名

これらの管理項目は、千手ブラウザの登録画面を使って入力します。入力した管理項目は千手マネージャ上の管理情報ファイルに保存されます。

1.2.2. 担当者の役割

千手システムの運用には、次の担当者を想定しています。

  • システム管理者

  • 運用オペレータ

  • アプリケーション開発者

  • 基盤管理者

1.2.2.1. システム管理者の役割

システム管理者は、業務システム全体を管理し、すべての運用を統括します。システム管理者の主な役割を次に示します。

  • 業務システム全体の構成管理

  • アプリケーション、機器の登録申請受け付け、認可

  • 管理情報の登録、削除

  • 運用指図書の作成 ( 運用オペレータへの指示 )

  • 障害発生時のオペレーション受付・指示

1.2.2.2. 運用オペレータの役割

運用オペレータは、システム管理者が作成した運用指図書を基に、実際の日常業務を行います。運用オペレータの主な役割を次に示します。

  • システム管理者の指示 ( 運用指図書 ) に従った運用操作

  • メッセージの監視と障害発生時の報告

  • 運用報告書の提出

  • 障害発生時のオペレーション対応

1.2.2.3. アプリケーション開発者の役割

アプリケーション開発者は、業務システムごとに存在し、アプリケーションや、千手システムの運用に使用する運用コマンドを開発します。

  • アプリケーションの管理

  • アプリケーション、および運用コマンドの設計・開発

  • アプリケーションの運用方式の決定

  • 障害発生時の調査・オペレーション対応・依頼

1.2.2.4. 基盤管理者の役割

基盤管理者は、管理するサーバーごとに存在し、サーバーやOS、サーバー上で稼働するアプリケーションの設定情報を維持管理します。

  • サーバー管理規定に従ったサーバーの設定維持管理

  • サーバーの設定変更要求に従った設定変更

1.2.3. 運用体制

業務システムを運用する場合の運用体制を明確にしておく必要があります。 図 1.8 に通常運用時の運用例を示します。

_images/image021.jpg

図 1.8 通常運用時の運用体制

  • システム管理者

    システム管理者は、通常運用時はシステム全体の管理を行い、運用オペレータに指示を与えます。 運用オペレータの監視項目 (永続的な監視項目、およびその日だけの監視項目)と監視基準、および報告体制を決定します。

    監視項目には、次のようなものがあります。

    • 管理対象ノード

    • 監視タスク

    • ネットワーク

    • バッチジョブ

    • パッケージ

    • 構成情報

    また、アプリケーション開発者が開発したアプリケーションのシステムへの登録申請を受け付け、システムへ登録します。

    原票を作成して、登録対象物の詳細を記入して申請するようにすると、業務システム内の資源を管理しやすくなります。

  • 運用オペレータ

    運用オペレータは、システム管理者からの運用指示書によって、実際のシステムの運用、および運用状況の監視を行います。

    システムになんらかの問題が発生した場合は、システム管理者に報告を行います。

  • アプリケーション開発者

    アプリケーション開発者は、ユーザーの要望などを受け、担当業務のアプリケーションを開発していきます。

    また、開発したアプリケーション、ジョブ、運用コマンドなどの管理項目のシステムに登録( 削除、変更 ) する場合の運用体制 ( 申請先、登録方法、運用手順 )、および障害発生時の対応を決定します。

  • 基盤管理者

    基盤管理者は、設定の変更を行い、変更が正しく行われたことを確認します。また、定期的にサーバーの設定情報を収集し、設定の変更の有無を管理します。

1.3. 千手システムの導入

ここでは、千手システム導入にあたって、必要な情報について説明します。

1.3.1. システムの導入

1.3.1.1. 千手マネージャおよび千手ブラウザのインストール

運用管理サーバー および運用管理コンソール に、千手システムのパッケージをインストールします。

( → 詳細は、 インストールガイド千手マネージャのインストール千手ブラウザのインストール を参照して下さい。)

1.3.1.2. 千手エージェントのインストール

管理対象ノードに千手システムのパッケージをインストールします。

( → 詳細は、 インストールガイド千手エージェントのインストール を参照して下さい。)

1.3.1.3. 管理情報ファイルの登録

千手システムで管理する各種資源を、運用管理コンソールから登録します。

  • 管理対象ノード(千手エージェント/千手センサー)の登録

    (詳細は、 千手ブラウザ(共通編) を参照して下さい。)

  • イベントサブシステムの管理項目の登録

    (詳細は、 イベント を参照して下さい。)

  • モニタリングサブシステムの管理項目の登録

    (詳細は、 モニタリング を参照して下さい。)

  • ジョブスケジュールサブシステムの管理項目の登録

    (詳細は、 ジョブスケジュール を参照して下さい。)

  • キャパシティサブシステムの管理項目の登録

    (詳細は、 キャパシティ を参照して下さい。)

  • コンフィグレーションサブシステムの管理項目の登録

    (詳細は、 コンフィグレーション を参照して下さい。)

  • ITリレーションの管理項目の登録

    (詳細は、 ITリレーション を参照して下さい。)

1.3.2. システムのディレクトリ構成

千手システム(千手マネージャ)を組み込んだ後の運用管理サーバーのディレクトリ構成は次のようになっています。なお、これらのディレクトリは、インストール時に設定したユーザーアカウント" senju " のホームディレクトリ下 ( この例では"$SENJUHOME"、"%SENJUHOME%" )に格納されます。

Linux版

(a)千手マネージャをインストールした場合。
/etc/senju.conf.d/        千手基本情報設定関連

$SENJUHOME
├/bin                  実行モジュール
├/dat                  定義ファイル(参照用)
├/ext                  AP サーバー監視用ライブラリファイル
├/inc                  開発用ヘッダファイル
├/install              インストーラー
├/lib                  ライブラリファイル
├/log                  ログファイル
├/samples              開発用サンプルファイル
├/store                蓄積ファイル
├/tmpout               一時ファイル用
└/unity_dat            定義ファイル(編集用)

Windows版

(a)千手マネージャをインストールした場合。
%ProgramData%\NRI
└senju.conf.d            千手基本情報設定関連

%SENJUHOME%
├bin                   実行モジュール
├dat                   定義ファイル(参照用)
├ext                   AP サーバー監視用ライブラリファイル
├inc                   インクルードファイル
├install               インストール関連ファイル
├lib                   ライブラリファイル
├libexec               ヘルパープログラム
├log                   ログファイル
├samples               開発用サンプルファイル
├store                 蓄積ファイル
├tmpout                テンポラリファイル
└unity_dat             定義ファイル(編集用)
アンインストール時に使用するプログラムを Common Filesフォルダ にコピーします。千手マネージャのアンインストール時にこのファイルも削除されます。
%CommonProgramFiles%\NRI\senju
└20.0.0               アンインストール時に使用するファイル
(b)千手DBコンポーネントをインストールした場合。
%CommonProgramFiles%\Microsoft SQL Server(デフォルト)              SQL Server Express用ディレクトリ(履歴データ格納用)

1.4. 千手システムの概要

1.4.1. Senju DevOperation Conductorサブシステムの概要

ここでは、Senju DevOperation Conductorの各サブシステムの概要について、説明します。

1.4.1.1. イベント

_images/image031.jpg

図 1.9 イベントサブシステムの画面

イベントは、千手システム内で発行されたメッセージを収集し、業務システムの運用・監視情報を運用管理サーバー側で一元管理します。

予め条件とするメッセージとそのメッセージに対するアクションを設定しておき、条件に該当するメッセージが出力された場合に、自動的に設定されたアクションを実行することが可能です。

また、複雑な手順を予め登録しておくことにより、その手順を自動実行させることができます。

イベントの概要を下記の図に示します。

_images/event_subsystem.jpg

図 1.10 イベントサブシステムの概要

  • メッセージの一元管理

    千手システムで発行されたメッセージを一元管理します。メッセージモニタに表示されるメッセージは、障害メッセージ、警告メッセージ、通常メッセージ、応答要求メッセージに分けて表示されます。

  • メッセージに対する自動アクション

    予め条件とするメッセージとそのメッセージに対するアクションを設定しておき、条件に該当するメッセージが出力された場合に、自動的に設定されたアクションを実行することが可能です。

  • メッセージに対する自動メール

    予め条件とするメッセージとそのメッセージに対するメール送信を設定しておき、条件に該当するメッセージが出力された場合に、自動的にメール送信することが可能です。メール送信の設定にメールテンプレートを使用できます。

  • メッセージに対する自動電話[EXTENSION]

    予め条件とするメッセージとそのメッセージに対するメール送信を設定しておき、条件に該当するメッセージが出力された場合に、自動的に電話呼び出しすることが可能です。

  • ランブックによる自動手順書実行[EXTENSION]
    複数のセクション/チャプター/分岐に前後関係を付け、それらの集まりを1つの実行単位として予めブックとして登録しておくことにより、ブックを自動実行することができます。
    分岐の条件として、前のセクションの終了コードや実行時の出力内容による分岐、環境変数の値による分岐、スケジュールによる分岐、手動による分岐と様々な条件を設定することができます。分岐によって、後続の処理を切り替えるような複雑なフローを作成することができます。
  • ログ情報の蓄積

    メッセージ情報の内容や、コマンド実行結果などの内容はログ情報としてファイルに記録されます。ログビューアからこれらのログ(メッセージログ、障害ログ 、コマンド実行ログ)を参照することができます。

  • アプリケーションへの応答

    アプリケーションから発行されたメッセージに対し、応答することができます。

  • メッセージガイド

    メッセージガイドとはメッセージID毎のメモを記録する機能のことです。メッセージID毎の対応を記録しておくことで、迅速な障害対応が可能となります。

1.4.1.2. モニタリング

_images/monitoring_image.jpg

図 1.11 モニタリングサブシステムの画面

モニタリングは、ネットワーク上に分散する複数のサーバーの稼働状態、およびサーバー上で稼働するアプリケーション群を、1台の運用管理サーバーから監視・制御するためのサブシステムです。これによって、業務システムの監視の効率化、および安定した運用を行うことができます。

モニタリングの概要を下記の図に示します。

_images/monitoring_subsystem.jpg

図 1.12 モニタリングの概要

  • システム情報監視
    CPUや仮想メモリの使用率、稼働プロセス数の各リソースの監視を行います。監視した結果が、予め設定したしきい値を超えた場合には、メッセージでの通知やコマンドを実行することができます。
    また、千手マネージャからのPingによる応答確認を行います。監視した結果により、メッセージを通知することができます。
  • ディスク監視

    管理対象ノードのディスク容量に関する、ディスク使用率や使用量、空き容量の監視を行います。監視した結果が、予め設定したしきい値を超えたり、下回ったりした場合には、メッセージでの通知やコマンドを実行することができます。

  • プロセス監視

    システム上で稼働しているアプリケーションやミドルウェアのプロセスの異常停止やリソース使用状況等の監視を行います。監視対象プロセス異常時にメッセージでの通知やコマンドを実行することができます。

  • 詳細情報監視

    上記の管理対象ノードのシステム情報監視/ディスク監視/プロセス監視に加え、次に示すようなより詳細な監視を行います。

    • 物理メモリ使用率

    • 実行待ちスレッド数やプロセス数

    • 親プロセスのプロセス別CPU使用率/メモリ使用量

    • 上位n個のプロセス別CPU使用率/メモリ使用量

    • 同一プロセス名稼働数の監視

    • システムポート稼働状況

    • ファイル改竄状況

    • Windowsサービスの稼働状況

    • コマンド実行にかかる時間

    • ディスクのI/O状況

    • OS稼働日数

    監視した結果が、予め設定したしきい値を超えたり下回ったりした場合に、メッセージでの通知やコマンドを実行することができます。

  • WEBサーバー監視[EXTENSION]

    URL応答確認、URL応答時間、Apache監視、IIS監視など、WEBサーバーの監視を行います。監視した結果が、予め設定したしきい値を超えたり下回ったりした場合に、メッセージでの通知やコマンドを実行することができます。

  • DBサーバー監視[EXTENSION]

    Oracle、SQL Server、DB2 UDB、PostgreSQLのデータベースシステムの監視を行います。監視した結果が、予め設定したしきい値を超えたり下回ったりした場合に、メッセージでの通知やコマンドを実行することができます。

  • MAILサーバー監視[EXTENSION]

    SMTP、POP3、IMAPのポートの応答確認やメール送受信にかかる時間の監視を行います。監視した結果が、予め設定したしきい値を超えたり下回ったりした場合に、メッセージでの通知やコマンドを実行することができます。

  • APサーバー監視[EXTENSION]

    WebLogic、WebSphere、JBoss、.NET Frameworkのアプリケーションサーバーの監視を行います。監視した結果が、予め設定したしきい値を超えたり下回ったりした場合に、メッセージでの通知やコマンドを実行することができます。

  • ERPパッケージ監視[EXTENSION]

    mySAPの監視を行います。監視した結果が、予め設定したしきい値を超えたり下回ったりした場合に、メッセージでの通知やコマンドを実行することができます。

  • ネットワーク監視

    ICMPを用いたパケット到達度や応答時間の監視や、SNMPを用いてのデータの送受信に関する情報などネットワークの監視を行います。監視した結果が、予め設定したしきい値を超えたり下回ったりした場合に、メッセージでの通知やコマンドを実行することができます。

  • バーチャリゼーション監視[EXTENSION]

    VMware/Hyper-Vの監視を行います。監視した結果が、予め設定したしきい値を超えたり下回ったりした場合に、メッセージでの通知やコマンドを実行することができます。

  • クラウドサービス監視[EXTENSION]

    クラウドサービス(Amazon Web Services)で提供される各種サービスの監視を行います。監視した結果が、予め設定したしきい値を超えたり下回ったりした場合に、メッセージでの通知やコマンドを実行することができます。

  • カスタム監視

    ユーザーがコマンド、WMI、SNMP、JMXなどを使った監視項目を任意に作成し情報の監視を行います。監視した結果が、予め設定したしきい値を超えたり下回ったりした場合に、メッセージでの通知やコマンドを実行することができます。

  • ログ監視

    Windowsのイベントログや、管理対象ノード上に他のアプリケーションが作成するテキスト形式のログファイルを監視し、予め設定した条件に一致する行が追加された場合、メッセージで通知します。

  • トラップ収集[EXTENSION] (SNMPコレクタ)

    SNMPコレクタとして設定された千手エージェントが、監視対象ノードからトラップ情報を収集することができます。収集したトラップ情報は、専用のログファイルに出力されます。

  • 時間帯監視

    時間帯監視機能では、管理対象ノードに対し監視スケジュールを日別、時刻別に定義し、監視する時間帯を決めることができます。監視しない時間帯に発行されたメッセージを表示するかどうかはメッセージ単位で設定することができます。

  • 時間帯別しきい値監視

    時間帯別しきい値監視では、タスクスケジュールを日別、時刻別に定義し、次に示す監視項目に対して時間帯毎の監視の開始/停止の切り替え、しきい値の変更および検査間隔の変更を自動的に行うことができます。

    • システム情報

    • ディスク監視

    • プロセス監視

    • 詳細情報監視

    • WEBサーバー監視

    • DBサーバー監視

    • MAILサーバー監視

    • APサーバー監視

    • ERPパッケージ監視

    • ネットワーク監視

    • バーチャリゼーション監視

    • クラウドサービス監視

    • カスタム監視

1.4.1.3. ジョブスケジュール

_images/image038.jpg

図 1.13 ジョブスケジュールサブシステムの画面

ジョブスケジュールは、業務システムで運用するジョブを運用管理サーバーで一元管理し、実行を制御するサブシステムです。運用日を定義したカレンダーを作成することで、ジョブを計画運用できます。主な特徴は以下の通りです。

ジョブスケジュールサブシステムの概要を下記の図に示します。

_images/jobschedule_subsystem.jpg

図 1.14 ジョブスケジュールサブシステムの概要

  • カレンダーによる計画運用

    予め、運用日を設定したカレンダーを作成し、ジョブ/ネット/フレームと関連付けることで、自動的に当日運用するジョブ/ネット/フレームを選択します。異なるジョブ/ネット/フレームに異なるカレンダーを割り当てることで、運用日によって実行するジョブ/ネット/フレームを選別することができます。

  • ジョブ/ネット/フレームの稼働状況表示

    ジョブ/ネット/フレームの稼働状況を運用管理コンソールで表示できます。稼働状況をグラフィカルに表示することで、ジョブ/ネット/フレームの運用状況を一目で確認することができます。

  • ジョブ/ネットの実行順序制御

    ジョブ/ネット同士の前後関係を指定したネットを作成することで、ジョブ/ネットの実行順序を制御できます。

  • 条件分岐によるジョブ制御

    ジョブの終了コードを条件にして分岐ジョブを設定できます。分岐ジョブによって、後続の処理を切り替えるような複雑なフローを作成することができます。

  • ジョブ/ネット起動のためのトリガ

    ジョブ/ネットを起動するタイミングを、トリガを定義して柔軟に設定することができます。

    • ファイル待ちトリガ

    • フレーム連携トリガ

    • その他ユーザー設定可能

  • 実行中ジョブ/ネット/フレームに対する操作

    運用管理コンソールから、実行中のジョブ/ネット/フレームに対して、一時停止、スキップなどの操作ができます。また、途中で中断したジョブ/ネット/フレームを再ランすることができます。

  • 複数ノードにまたがるジョブ/ネット/フレーム実行
    複数のノードにまたがったジョブ/ネット/フレームの実行を制御できます。ジョブ/ネット/フレームの実行を複数のノードに割り振ることで、業務システムの柔軟な運用が可能になります。
    ノードグループネット機能を使用することで複数ノードでの同一ジョブ実行が容易に設定できます。また、ロードバランス機能を使用すれば、稼働中のジョブ数が全ノードで均等になるように実行時にジョブを割り振ることもできます。
  • ジョブのログ出力

    ジョブが出力するログをファイルに取得することができます。

  • リソースによるジョブ/ネットの起動の排他
    ジョブ/ネットにリソースを指定することにより同時に稼働するジョブ/ネットに制限を設けたり、排他させることができます。
    リソースは異なるフレームのジョブ/ネット間や、運用日付の異なるフレームのジョブ/ネット間にも使用できます。
  • ジョブレポートによる稼働履歴の参照

    ジョブ/ネット/フレームの稼働履歴をガントチャート、グラフ、リストで参照することができます。

  • ジョブアクティビティによる稼働履歴の参照

    ジョブ、ネット、フレームの稼働履歴を元にしたタイムラインを表示することができます。

  • ジョブサービスによる業務フローの視点での監視
    指定した時刻にジョブ/ネット/フレームが起動/終了していること、自動サイクル運用が成功していることを監視し、監視結果をジョブサービスモニタでサービスグループ単位で一覧表示することができます。
    これにより、遅延監視のチェックリストを業務フローの視点、サービスの視点で確認することができます。
  • ジョブチェッカによる影響チェック

    後続ジョブ/ネットの影響チェック機能は、異常終了などで終了遅延が起きた場合や、ジョブの構成変更時に、後続ジョブ/ネットへの影響範囲(影響パス)を把握することができます。

  • すべてのジョブに対する自動での遅延監視

    設定ファイルに基づき、指定時間以上ジョブが稼働していないかを監視することができます。指定時間内に終了していなければ、通常/警告/障害メッセージが出力され、ジョブの実行状況を実際の実行状況に自動的に復旧します。自動遅延監視では個別のジョブに遅延監視の設定を行う必要はなく、稼働中のすべてのジョブの監視が可能です。

  • 更新記録の書き出し

    営業日カレンダー、およびジョブスケジュールの指定したエンティティの過去の更新記録を書き出すことができます。書き出しできるエンティティは次のとおりです。

    • 営業日カレンダー

    • 稼働日カレンダー

    • トリガ

    • リソース

    • 動作環境

    • 動作環境プール

    • ジョブ

    • ネット

    • システム

    • ジョブサービス

    • ジョブレポート

    更新記録の書き出しにより、ジョブやネットなどに対して、いつ、誰が、どのような変更をおこなったかを把握することができます。

1.4.1.4. キャパシティ

_images/image048.jpg

図 1.15 キャパシティの画面

キャパシティサブシステムでは、モニタリングサブシステムから取得した各サーバー、ネットワークの利用状況や負荷状況などの稼働状況を履歴データとして蓄積し、グラフ表示します。これらのデータを、キャパシティプランニングや稼働状況レポートに活用したり、障害発生時のトレンド解析に活用したりすることで、サービスレベルの維持、向上を可能とします。

キャパシティの概要を下記の図に示します。

_images/capacity_subsystem.jpg

図 1.16 キャパシティサブシステムの概要

  • 稼働状況履歴データの蓄積
    モニタリングサブシステムの結果取得したデータの推移を蓄積し、グラフ化、分析することができます。
    千手システムでは、検査間隔毎に取得した履歴データを以下の3種類のサマリテーブルに蓄積します。
    • 時間

    監視タスクの履歴データをサマリテーブルへ蓄積する方法には以下の5種類があります。

    • 平均値

    • 最小値

    • 最大値

    • 合計値

    • 最新値

  • 蓄積データのグラフ表示
    蓄積された履歴データをグラフ表示することができます。
    グラフ定義を登録しておくことで任意の複数タスクを1つのグラフに表示させデータの変化傾向等を視覚的に行うことができます。グラフの表示対象期間と異なる期間の履歴データをあわせてグラフに表示したり、ある期間ごとに履歴データがしきい値を超えている割合をグラフ化したりすることによって、より柔軟にキャパシティの傾向分析を行うことが可能になります。
    グラフには履歴データを時系列で表示する時系列グラフ、監視対象ごとに比較するための監視タスク系列グラフを作成する事ができます。
    またグラフの種類には以下の5種類が用意されており、使用目的に応じて最適な表示方法を選択することができます。
    • 棒グラフ

    • 折線グラフ

    • 積上げ棒グラフ

    • 積上げ折線グラフ

    • 円グラフ

  • グラフモニタの印刷

    グラフモニタに表示されているグラフを印刷することができ、マシン稼働レポートの作成などを容易にします。

  • グラフデータの書き出し
    データをファイルとして出力することができるため、データを保存することができ、実際の値を取得することができるほか、任意のアプリケーションを使用し蓄積したデータをグラフ表示以外にも幅広く利用することが可能です。
    グラフモニタからデータを以下の4種類の形式でファイルへの出力を行うことができます。
    • テキスト(スペース区切り)

    • テキスト(タブ区切り)

    • CSV(カンマ区切り)

    • HTML形式

  • Webアカウントの設定

    Webからのログインアカウントを登録でき、アカウント毎にWeb画面からの参照範囲ノードを限定することができます。

1.4.1.5. コンフィグレーション

_images/image052.jpg

図 1.17 コンフィグレーションサブシステムの画面

コンフィグレーションサブシステムでは、ネットワーク上に分散する複数のサーバーの構成情報を収集し、一定期間蓄積します。収集の際に、構成変更の有無を自動的に検知したりすることができます。蓄積した構成情報は、検索しダウンロードすることで、内容を参照することができます。これにより、サーバーの構成情報の管理を行うことができます。

コンフィグレーションの概要を下記の図に示します。

_images/configuration_subsystem.jpg

図 1.18 コンフィグレーションの概要

  • 千手構成管理項目

    千手で予め登録されている構成管理項目を、定期的に取得することができます。千手構成管理項目には、次のものがあります。

    • 千手基本情報

    • 千手パッチ情報

    • ホスト情報

    • ディスク情報

    • ネットワーク情報

    • ソフトウェア/パッチ情報

    • サービス情報

    • ユーザー情報

    • ログイン情報

    変更を検出した場合には、メッセージで通知することができます。

  • ファイル取得

    サーバー上の各種コンフィグレーションファイルの内容を定期的に取得することが出来ます。取得した内容の変更を検出した場合には、メッセージで通知することができます。

  • ファイルリスト情報取得

    サーバー上の各種コンフィグレーションファイルの概要(モード、オーナー、サイズ、タイムスタンプ、チェックサム)を定期的に取得することが出来ます。取得した情報の変更を検出した場合には、メッセージで通知することができます。

  • コマンド実行

    サーバー上の各種コンフィグレーション情報を取得するために、定期的にコマンドを実行し、そのコマンドの標準出力を取得することが出来ます。取得した情報の変更を検出した場合には、メッセージで通知することができます。

  • SNMP項目

    サーバー上の各種コンフィグレーション情報を取得するために、SNMPを用いることが出来ます。取得対象のOIDを設定することにより定期的にSNMPを送信し、指定したOIDの情報を取得することが出来ます。取得した情報の変更を検出した場合には、メッセージで通知することができます。

  • WMI情報

    Windowsが構成管理ノードの場合は、サーバー上の各種コンフィグレーション情報を取得するために、WMIを用いることが出来ます。取得対象のWMI名前空間やクラス名を設定することにより、定期的にクラスの情報を取得することができます。取得した情報の変更を検出した場合には、メッセージで通知することができます。

  • レジストリ情報

    Windowsが構成管理ノードの場合は、サーバー上の各種レジストリ情報を定期的に取得することが出来ます。取得した情報の変更を検出した場合には、メッセージで通知することができます。

  • イベントログ情報

    Windowsが構成管理ノードの場合は、サーバー上の各種イベントログ情報を定期的に取得することが出来ます。

1.4.2. 千手システムのユーザーアカウント

千手ブラウザでは、様々な監視・運用項目を定義、操作する際に、適切な権限が必要となります。

千手ブラウザでは、千手ドメインに接続する際、ユーザー名とパスワードか、外部認証を指定します。このユーザーは、必ずユーザーグループに属しており、そのグループに割り当てられた権限によって、可能な操作が決まっています。ユーザーをユーザーグループに所属させることで、権限に応じた操作のみをさせることができます。

また、ユーザーに対してスコープを設定することにより、必要なノード、ノードグループ、実行システムのみを参照・操作させることができます。

これらの機能により、柔軟なセキュリティ管理を行うことができます。

_images/image055.jpg

図 1.19 千手システムのユーザーアカウント

1.4.2.1. 操作権限の種類

千手システムでは、千手ブラウザ上での操作権限を、次の5つに分けています。

  • ユーザー管理
    ユーザーの新規作成、削除、パスワード変更が可能です。また、ライセンスキーの変更が可能です。
    ライセンスキーの変更は、 ライセンスキーの変更 を参照して下さい。
  • データの編集

    ノードの定義、ジョブやパッケージなどユーザーが定義できるエンティティの新規作成、変更、削除が可能です。

  • 操作

    プロセスやジョブの実行などの操作が可能です。

  • 参照

    現在の各設定項目の参照と状態の監視が可能です。

  • ダウンロード

    コンフィグレーション機能により蓄積した構成情報のダウンロードが可能です。

1.4.2.2. ユーザーグループ

千手ユーザーには、次のグループがあり、それぞれ付与されている権限が異なります。このグループの権限は固定されています。

登録されるユーザーはすべて、このグループのいずれか1つにだけ属します。

  • Administrators グループ
    すべての権限(ユーザー管理、データの編集、操作、参照)が付与されているグループです。このグループに属するユーザーは、千手ブラウザ上でのあらゆる操作が可能です。
  • Managers グループ
    データの編集、操作、参照の権限が付与されているグループです。
  • OpeEditorsグループ
    データの編集、参照の権限が付与されているグループです。
  • Operators グループ
    操作権限、参照権限が付与されているグループです。
  • Users グループ
    参照権限のみが付与されているグループです。
  • Viewersグループ
    参照権限が付与されているグループです。このグループで千手システムにログインすることで他のユーザーグループに切り替えることが出来ます。
  • WEBUsers グループ
    Webブラウザからログインして、許可されたノードに関するデータの編集、参照権限のみが付与されているグループです。
  • WEBViewersグループ
    Webブラウザからログインして、許可されたノードに関する限定したデータの編集、参照権限のみが付与されているグループです。
  • XferManagersグループ(※1)
    千手ダウンローダから千手構成ファイルサーバーにログインして、全てのノードに関するデータのダウンロード、参照が可能です。
  • XferUsersグループ(※1)
    千手ダウンローダから千手構成ファイルサーバーにログインして、許可されたノードに関するデータのダウンロード、参照権限のみが付与されているグループです。

注釈

(※1)ダウンローダでのみ使用できるユーザーです。下位バージョンとの互換性のために機能を残していますが、次期バージョン以降で廃止予定です。

例えば、Usersグループのユーザーは、ジョブスケジュールの参照は可能ですが、定義や実行はできませんし、Managersグループのユーザーは、ジョブスケジュールの参照・実行・定義は可能ですが、ユーザーの作成はできません。

1.4.2.3. ユーザーとパスワードの管理

  • ユーザーの新規作成
    ユーザーの新規作成は、ユーザー管理の権限を持つユーザー ( Administrators グループのユーザー ) のみが行います。
    また、1つのユーザー名が複数のユーザーグループに属する事はできません。
  • ユーザーグループの変更
    ユーザーグループの変更は、Administratorsグループのユーザーのみ可能です。
  • パスワードの設定/変更
    パスワードについては、ユーザー本人がそのユーザーのパスワードを設定、変更できます。なお、自分のパスワードを変更する際は、本人認証のため、現在設定されているパスワードを入力する必要があります。
    また、ユーザー管理の権限を持つ ( Administrators グループに属する )ユーザーは、あらゆるユーザーのパスワードを変更する事ができます。

警告

パスワードを忘れるなどしてAdministrators グループに属するユーザーで接続できなくなった場合、再度パスワードを設定したり新たにユーザーを作成することができなくなります。Administrators グループに属するユーザーのパスワードは忘れないようご注意下さい。

参考

パスワードを認証する際に、LDAPやActive Directoryの外部認証を利用できます。詳細は、 外部認証の設定方法 を参照して下さい。

  • 予約アカウント

    初めて運用管理サーバーに接続する際は、予約アカウントである、"senju"でログインします。"senju"の最初のパスワードは共通ですので、セキュリティのため、必ず変更するようにして下さい。

  • ドメインに接続中のユーザーの変更

    ドメインに接続中のユーザーのユーザーグループを変更しても、その変更内容が有効となるのは、再接続した後です。よって、接続中のユーザーの権限はそのまま保持されます。

    また、Administratorsグループのユーザーによって、接続中のユーザーのパスワードが変更された際、続けて、そのユーザーが再度パスワードを変更するためには、現在のパスワードにはAdministratorsグループのユーザーが設定したパスワードを指定します。

    接続中にユーザーアカウントが削除された場合でも、ドメインには接続したままですが、再接続の時にユーザー名が無いため、ログインできなくなります。

  • ユーザーアカウントポリシー

    ユーザーのパスワードにおいて、以下の設定ができます。

    • 最低限必要なパスワード長

    • 単純なパスワードでないかのチェック

    • 過去に使用したパスワードを使用していないかのチェック

    • パスワード変更後の有効期限

    • ログイン時のパスワードを間違えた回数でのアカウントのロックアウト

  • ユーザースコープ機能

    ユーザーに対してスコープを設定できます。 ユーザースコープ機能を使用しているユーザーは、システム全体の操作はできなくなり、設定されたノード/ノードグループ、実行システム/フレームのみ参照・操作が可能となります。 詳細は ユーザースコープ機能 を参照して下さい。

  • ネーミングフィルタ機能

    ユーザーが表示可能な千手オブジェクトを設定できます。 ネーミングフィルタ機能を使用しているユーザーは、指定されたフィルタに適合する千手オブジェクトのみ参照・操作が可能になります。 詳細は ネーミングフィルタ機能 を参照して下さい。

.