|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
| Management Module | ||||||||||||
|
以降で述べるManagement/Provisioning/Monitoring Moduleは、Update Moduleとは異なり、Red Hat Enterprise Linuxのサブスクリプションに追加する形でサブスクリプション契約が必要となります。 Management Moduleによって提供される主な機能を表3に示します。
表3:Management Moduleの主な機能 |
||||||||||||
| 多数のシステムをグループ化して単一のシステムと同様に扱える | ||||||||||||
|
Linuxは他のOSと比べるとリモートでのメンテナンスが比較的容易ですが、それでも10台、20台とサーバ増えてくるとエラッタの適用だけでもかなりの作業を要します。実際の事例ですが、Red Hat Enterprise Linuxのアップデート(3〜6ヶ月ごとにリリースされ、通常200ぐらいのRPMパッケージで構成)時には、更新に3日もかかっているということです。これだけの時間がかかるのには2つ理由があります。 まず第1にシステムを1台ずつ更新しているということ、第2にRPMパッケージをダウンロードするのに時間がかかっている(ネットワークの帯域を浪費している)ということです。前者を解決するのがManagement Moduleで、後者を解決するのはRHN Satellite Server/Proxy Serverになります。 |
||||||||||||
| 管理者に異なる権限やグループを割り当てる | ||||||||||||
|
システムの数が多くなってくると、一般に管理者も複数になります。しかし、すべての管理者が同様にシステム管理の全権限を持っているという状態は、個人情報保護法などの法令や、法令に抵触しないまでもコーポレートガバナンスという観点から考えれば、望ましいものではありません。 Management Moduleでは、すべての操作が可能なorganization administratorよりも権限が制限された管理用アカウントを作成することが可能です。例えばチャンネルの操作だけが可能なchannel administratorや、設定ファイルが含まれるConfig Channelの操作だけが可能なconfiguration administratorなどです。 また、あるアカウントにはあるグループだけを管理させることも可能です。例えば、WebサーバグループはAさん、メールサーバグループはBさん、それらのサーバをすべて含むLinuxサーバグループはリーダであるCさんが管理するといった具合です。この場合、AさんからはBさんが管理するメールサーバは見えませんし、その逆も同じです。 |
||||||||||||
| RPMパッケージやシステム情報を元にシステムを検索可能 | ||||||||||||
|
RHNへのシステムの登録時には、パッケージプロファイル(RPMパッケージの一覧)やシステムを構成するハードウェアの情報などが、ユーザのアカウント情報と共に暗号化されて送信されます。これらの情報はRHN上のデータベースに登録されており、検索の対象とすることが可能です(図3)。 |
||||||||||||
| パッケージプロファイルを比較してシステムの違いを迅速に判別 | ||||||||||||
|
インストール時にはまったく同じRPMパッケージ構成であったシステムが、長期の運用における複数回の更新によって、差異が発生することがあります。しかし、up2dateコマンドでRPMパッケージを更新する際、あるいはrpmコマンドでRPMパッケージの操作を行った場合でも、「up2date -p」コマンドを発行すればRHNのデータベース上のパッケージプロファイルは更新されます。 したがって、このデータベースを対象に比較を行えばシステムの差異を判別することは容易です(図4)。 |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||



