Skip to content

マガジン(米国翻訳) ｜ ニュースレター(日本)のトップ

レッドハットニュース
レターの新規御登録

バックナンバー


第4号(2007年1月)

Red Hat Network Part2 --実装モデル--


必要に応じて選択可能なモジュール


　前号ではRed Hat Network(以下RHN)とは何なのか、どういった製品があるのか、RHNによってお客様の課題がどのように解決出来るのかをご紹介いたしました。なぜRHNがお客様にとって必要なのかがご理解いただけたのではないかと思います。しかし実際にご導入いただくためには、お客様のニーズを的確に認識し、最適なRHNの構成をご選択いただく必要があります。

　この観点でもRHNは優れた設計がなされています。Modularity、つまり「運用要件に応じて選択可能なモジュール」という考え方です。まず、個別のモジュールをご紹介する前に具体的な事例で見てみましょう。

典型的なエッジサーバでの事例


　あるお客様のデータセンタでは、2/4wayのラックマウントサーバを中心に、ブレードサーバを含む百数十台のシステムによって、オンラインショッピングサイトを運用しています。ビジネスとしては非常に成功しており、毎月数台、多い月には10台を超えるサーバが増えていました。当然、毎月のように既存のウェブサーバやメールサーバと同じ設定のサーバを構築する作業が発生しますし、既存のサーバに対しても自社開発のショッピングプログラムが確実に動作することをテストしてから、セキュリティエラータを適用していく必要がありました。

　このお客様に対するソリューションとして考えられたのは、RHN Satellite Server/Proxy ServerとProvisioning/Management/Monitoring Moduleの導入です。
  • Satellite Serverによってカスタムコンテンツの配信が可能
    • →自社開発のアプリケーションもRed Hat Enterprise Linux(以下RHEL)に同梱されるRPMパッケージ同様に配布することが可能。そのアプリケーションのバージョンアップの際に複数のRPMパッケージを更新する必要がある場合は、エラータも自社で発行可能（連載第１回参照）
  • Proxy Serverによって150台を超えるサーバにコンテンツ配信が可能
    • →Satellite Server上で動作するwebサーバの負荷をProxy Serverに分散。
  • Management Moduleによってシステムをグループとして扱うことが可能
    • →１台のシステムは複数のグループに所属させられるので用途別にエラータが適用できる（図１）。「テスト」グループに先行して適用しテストを実施、その後「本番」グループに適用する、といった運用が可能に。
  • Provisioning Moduleによってプロファイル・設定を管理することが可能
    • →新規システムのインストール・設定や、既存システムのプロファイルをベースにした新しいハードウェア上でのシステム構築を自動化。

    RHN2_1
    図１　グループ毎にエラータ（RPMパッケージ）が適用可能


  • Monitoring Moduleによってパフォーマンスモニタが可能
    • →システムの増設時期の判断の基準としてモニタリングによるデータが利用可能になり、ハードウェアのモデルチェンジやデータセンタのラック本数などを加味して、ハードウェアの在庫を持たずに経済的な増設計画が立てられるように。
この事例の場合RHNの製品群を全て採用しましたが、システム要件にあわせて４つのモジュールを適切に組み合わせることで、Linux（Satellite ServerがあればSolarisも）の管理をRHNに集約することが可能です。

モジュールとは？


　「モジュール」という言葉は、ITシステムの様々な場合で色々な使われ方をします。まずRHNのモジュールとは何かを簡単にご説明します。
　モジュールは個別のサーバにはインストールされません。モジュールはRHNセントラルサーバあるいはRHN Satellite Serverに存在するプログラム群です。従って、この連載でも「Management Moduleの導入」と簡易に言い表していますが、正確には「Management Moduleの利用権を付与する」＝Entitlement という呼び方が正しいことになります。実際に利用権を付与するために必要な操作は、ウェブインターフェースでチェックボックスをチェックするだけです（図２）。

ただし、Provisioning Moduleの利用権を付与するだけでは、その機能の１つである「設定ファイルの個別サーバへの適用」は出来ません。この機能を利用するには、rhncfgパッケージを個別のサーバにインストールする必要があります。 同様にMonitoring Moduleの機能を利用するには、rhnmdパッケージをインストールする必要があります。


　 図２　モジュールの利用権の付与はチェックボックスでの操作のみ

Update Module


　Update Moduleの利用権は全てのRHELのサブスクリプションに含まれています。従って、製品に同梱されるサブスクリプションIDを登録、更新すれば、Update Moduleは利用できます。特に他のモジュールを購入せずにRHNセントラルサーバを利用しているのであれば、それはUpdate Moduleの機能を利用していることになります。

　Update Moduleによって提供される主な機能は以下になります。
  • エラータやOSのアップデートを簡単に入手可能
    • RHNへのシステムの登録がなされていれば、up2dateコマンドの実行だけで自動的にRPMパッケージの依存関係を解消し、新規にインストール・更新することが可能です。また、RHNセントラルサーバから、サブスクリプション契約のある全ファミリーの全バージョンのインストーラが入手可能です。例えば、RHEL ESのサブスクリプショ　　ン契約があれば、RHEL AS 2.1/3/4（2006年10月現在）の、x86/x86_64/ia64のいずれのアーキテクチャのインストールイメージも入手可能です。
  • 不要なRPMパッケージをウェブインターフェースから削除可能
    • システムにインストールされているRPMパッケージの全リストは「パッケージプロファイル」と呼ばれ、up2dateコマンドの実行時に自動的にRHNに送信されます。RHNではパッケージプロファイルをベースに削除対象とするRPMパッケージをウェブインターフェースで選択し、システムの次回のRHNへのチェックイン時に実際に削除されます。
  • 最新のセキュリティフィックスでシステムを自動更新
    • プロダクションシステムで全てのRPMパッケージを自動更新することは避けるべきですが、システムで提供する主要なサービスに関連しない、あるいは影響が少ないRPMパッケージを含むエラータについては自動更新することで、サーバの外部からの攻撃だけではなく、サーバの一般アカウントを用いて行われる攻撃＝ローカルエクスプロイトに対するセキュリティも向上させることにつながります。例えば、ウェブサーバであればhttpdパッケージやopensslパッケージなどは自動的に更新しないように設定することが可能です。

Management Module


　Management/Provisioning/Monitoring Moduleは、Update Moduleとは異なり、RHELのサブスクリプションに追加する形でサブスクリプション契約が必要となります。

　Management Moduleによって提供される主な機能は以下になります。
  • 多数のシステムをグループ化して単一のシステムと同様に
    • Linuxは他のOSと比べるとリモートでのメンテナンスが比較的容易ですが、それでも10台、20台と増えてくるとエラータの適用だけでもかなりの作業を要します。実際のお客様の事例ですが、RHELのアップデート（3〜6ヶ月毎にリリースされ、通常200ぐらいのRPMパッケージで構成）時には、更新するのに3晩かかっているということです。これだけの時間がかかるのには２つ理由があります。まず第１にシステムを1台ずつ更新しているということ。第２にRPMパッケージをダウンロードするのに時間がかかっている＝ネットワークの帯域を浪費しているということです。前者を解決するのがManagement Module、後者を解決するのはRHNSatellite Server/Proxy Serverということになります。
  • 管理者に異なる権限やグループを割り当てる
    • システムが多数になってくると、一般に管理者も複数になります。しかし、全ての管理者が同様にシステム管理の全権限を持っているという状態は、個人情報保護法などの法令や、セキュリティ保護、コーポレートガバナンスという観点からはあまり望ましいものではありません。また、あるアカウントにはあるグループだけを管理させることも可能です。例えば、ウェブサーバグループはAさん、メールサーバグループはBさん、それらのサーバを全て含むLinuxサーバグループはリーダであるCさんが管理するといった具合です。この場合、AさんからはBさんが管理するメールサーバは見えませんし、その逆も同じです。
  • 検索機能により、RPMパッケージやシステム情報などをベースにシステムを認識
    • RHNへのシステムの登録時には、パッケージプロファイル（RPMパッケージの一覧）やシステムを構成するハードウェアの情報などがユーザのアカウント情報と共に、暗号化されて送信されます。これらの情報はRHN上のデータベースに登録されており、検索の対象とすることが可能です（図３）。


    　 図３　CPUが3000MHz（3GHz）以下のシステムを検索した結果

  • パッケージプロファイルを比較してシステムの違いを迅速に判別
    • インストール時には全く同じRPMパッケージ構成であったシステムが、長期の運用における複数回の更新などによって、差異が発生してしまうことがあります。しかし、up2dateコマンドでRPMパッケージを更新する際、あるいはrpmコマンドでRPMパッケージの操作を行った場合でもup2date -pコマンドを発行すれば、RHNのデータベース上のパッケージプロファイルは更新されます。従って、このデータベースを対象に比較を行えばシステムの差異を判別することは容易です（図４）。


　 図４　２つのシステムを比較した結果、nmapパッケージは１台にしか無い

Provisioning Module


Provisioning Moduleによって提供される主な機能は以下になります。
  • 事前定義のプロファイルを用いて、あるいはクローンによってシステムを配置
    • Provisioning Moduleによって提供されるKickstartライターを用いると、Kickstartファイルの作成や管理が容易に可能です。KickstartはLinuxの自動インストールの仕組みです。また、Activation Keyと呼ばれる、インストール時にチャンネルへの登録を自動的に行うための仕組みと組み合わせることで、インストールからRHNへの登録までが自動化できます。これらの情報を事前に定義したおけば、ベアメタル、つまり事前定義された構成でのクリーンインストールが自動的に出来るようになります。また、事前に定義されていなくても、すでに配置されているシステムのプロファイルをベースに新規システムを配置することも可能となります。
  • 設定ファイルをRHNで管理・配布する
    • この機能については、前号でご紹介いたしました。前号をご参照下さい。
  • スナップショットとロールバック
    • RHNにシステムが登録され、Provisioningが有効になっていると、以降の様々なRHN関連の作業内容が自動的にスナップショットとして記録されます。パッケージプロファイルの変更、つまりRPMパッケージの追加・更新・削除や、システムグループへの登録・削除、管理ユーザの変更などの作業など、RHNのデータベースに変更が発生するものはすべて記録されています。実際のシステムではスナップショットは膨大になるため、任意のある時点でスナップショットにタグ＝名前を付けることが可能です。例えば、RHELのUpdateを適用する前の状態を、"Before Update"などとしておけば、どのスナップショットなのかが容易に判別可能です。
    これらのスナップショットは、ロールバックの際に用いられます。上述の例で、Updateを適用したところ、本来の動作と異なってしまった、あるいはサービスが継続出来なくなってしまった場合には、"Before Update"スナップショットを選択して、ロールバックするのに必要なのは、ブラウザ上での数クリックのみです。これにより、Update適用前の状態に戻すことが可能です。

Monitoring Module


　Monitoring Moduleの利用にはRHN Satellite Serverが必須となります。RHNセントラルサーバには全世界で数百万台のシステムが登録されており、個別のシステムについて最大1分ごとに情報を 収集することは、技術的にもセキュリティの観点からも難しいのがその理由です。
　Monitoring Moduleによって提供される主な機能は以下になります。
  • システムにほとんど負荷をかけないProbeを配布
    • Probeによってモニタ出来る項目は非常に多岐に渡るため、紙面ですべてはご紹介できないのですが、LinuxのCPUやディスク、ネットワークの利用率に始まり、OracleやMySQLなどのデータベースのクエリ数に至るまでの項目が含まれます。
  • Probe Setを作成可能
    • 複数のProbeを多数のシステムに設定する作業は手間と時間を浪費します。Monitoring Moduleでは複数のProbeをSetとしてグループ化することが可能です（図５）。


    　 図５　5つのProbeから構成されるProbe Setの例

  • クリティカルな閾値に達した際にメールで管理者にエラーを通知
    • Monitoring Moduleはエラーモニタというよりはパフォーマンスモニタという性格が強いのですが、簡易的にエラーモニタとして利用できるようにも考慮されています。

RHEL 20,000台を管理する方法とは


　ここまでのご説明で、Management Moduleによって数十台、数百台のサーバをグループ化して管理し、システムの追加はProvisioning Moduleによって自動化、運用がスタートするとMonitoring Moduleで監視するという流れはおわかりいただけたかと思います。

　大規模な例として、あるお客様は20,000台のRHELをお持ちです。Updateの際には以前ご紹介したように200以上のRPMパッケージがリ リースされます。このすべてを更新するということは稀ですが、仮に200MBのデータに相当するとします。200MB×20,000台ですから 4,000,000MB、つまり4TBのデータをダウンロードする必要が発生します。これは非常に不経済なことです。なぜなら、あるサーバがダウンロー ドしたRPMパッケージは、すでに隣のサーバがダウンロードしているかもしれないからです。また、20,000台がすべてインターネットにアクセスできるということも珍しいはずです。通常はデータベースやアプリケーションサーバはバックセグメント、つまりインターネットに接続出来ないようにするのがセキュリティの観点からは望ましいはずです。
　こういった問題に対するソリューションとして、RHN Satellite Server/Proxy Serverをご紹介いたします。

選択基準


　最初に判断しなければならないのは、セキュリティの問題です。もしお客様のシステムが非常にクリティカルな情報を扱うシステムである場合、RHN Satellite Serverは必須だと言えるでしょう。
  • インターネットに接続しない（できない）
    • 外部ネットワークからの攻撃を考慮しなくても良いということは、セキュリティ上、大きな利点があります。しかし、RHNセントラルサーバと通信する必要があるHostedモデルではインターネットへの接続は必須要件です。
  • セキュリティアップデートは適用しなければならない
    • 内部LAN、あるいはローカルユーザからの攻撃を考慮すると、外部ネットワークに接続しないからといって、セキュリティアップデートを適用しなくて良いということではありません。ユーザに悪意が無くても、Winnyなどのソフトによって偶発的に外部に情報が漏洩する可能性は排除できません。
　次に判断する必要があるのは、お客様のシステムの規模ということになります（図６）。


　 図６　サーバの台数で見る各配置モデル・モジュールの選択基準

　RHNの追加モジュールについては、50台前後が採用判断の境目と言えます。Management Moduleは50台より少なくても、システムごとにそれほど差異が無ければ導入することで管理・運用の大幅な省力化が図れます。例えば、ロードバラン サの下位に同じ構成のウェブサーバが10数台あるようなシステムが典型的です。

Hosted Model


　最初にご紹介する配置モデルは、デフォルトのクイックセットアップであるHosted Model（図７）です。


　 図７　Hosted Model

　このモデルでは全てのユーザシステムはインターネットを介して直接RHNセントラルサーバに接続されています。このため、システムプロファイルやエ ラータ・RPMパッケージはRHNセントラルサーバに保持されます。それらのコンテンツのやりとりは基本的に暗号化通信（https）で行われますし、 RPMパッケージにはデジタル署名が含まれ完全性を検証することが可能です。

　Hosted ModelでRHN利用を行なう場合、考慮しなければならないのは以下の２点です。
  • 人件費をTCOとして計上しているか。
    • 現在のITコストを構成する要素のうち、最大のものは人件費です。もしIT部門の人件費が非常に安価であれば、人海戦術、あるいは時間をかけてシステムの運用・管理を行うことは可能です。
  • トラブル対応にどのくらいの猶予があるか。
    • 上述のように人件費があまり重要でない場合でも、ITに関するトラブル対応の善し悪しは企業の評価に関わります。数年前ならともかく、現在は大企業のシステムトラブルはニュースとして報道されますし、それは株価を初めとする企業評価の下落につながります。トラブルを短時間で収束させるには、残念ながらHosted Modelでは限界があります。

Hosted + Proxy Model


では、人件費を抑えつつトラブル対応を適切に処理するためのシステムにはどんなものがあるのか見てみましょう。

　次にご紹介するのは、Hosted ModelにRHN Proxy Serverを追加したモデルです。


　 図８　Hosted + Proxy Model


　このモデルでは、Hosted Model同様、全てのコンテンツはRHNセントラルサーバに保持されますが、帯域の節約のためにRHN Proxy Serverが一部のコンテンツ（RPMパッケージやパッケージヘッダファイル）をキャッシュし、各ユーザシステムに配信します。特定のコンテンツに着 目すると、１台目のユーザシステムからのリクエストの際は、インターネット回線の速度でダウンロードされますが、２台目以降についてはRHN Proxy ServerのローカルキャッシュからLANの速度でダウンロードされることになります。

　条件により異なりますが、１台のRHN Proxy Serverで最大150台程度のユーザシステムに対して同時にコンテンツを配信できます。

Satellite Model


　エンタープライズシステムのためのRed Hat Networkが、RHN Satellite Serverです。端的に言ってしまえば、Red Hatが米国に設置しているRHNセントラルサーバとほぼ同等のシステムをお客様のサイトに設置できる製品ということになります。「ほぼ同等」と書いた のにはいくつか理由があります。
  • Monitoring Moduleの利用が可能
    • 前半でもご紹介したように、RHNセントラルサーバには全世界で数百万台のシステムが登録されているため、Monitoring Moduleは利用できません。RHNSatellite Serverがお客様のサイトにあれば、Monitoring Moduleをご利用いただけます。
  • Sun Solarisを管理対象にすることが可能
    • S2L（Solaris to Linux）という流れでは、全面的にRHELに切り替わる前段階としてSolarisとRHELが混在する状況が発生します。RHN Satellite Serverは、RHELだけではなくSolarisのサーバも管理対象とすることができます。管理が可能なSolarisのバージョンは8/9/10（x86は9/10）です。Management Moduleによるグループ化やProvisioning Moduleによるキックスタートなどもサポートされます。
　上述の２点が主なものですが、RHN Satellite ServerはRHNセントラルサーバよりも機能が多いので、「ほぼ同等」とご紹介したわけです。


　 図９　Satellite Model

　RHN Satellite Serverは構築時にRHNセントラルサーバと通信する必要がありますが、その後はインターネット接続は必須ではありません。インターネットに接続し ない場合は、エラータ等のデータはチャンネルコンテンツISO（CD-ROMイメージファイル）として配布されていますので、このデータをダウンロード してRHNセントラルサーバと同期します。

　カスタマイズコンテンツもRHN Satellite Serverによって利用可能になります。サードパーティ製のアプリケーションのRPMパッケージを配布するためにカスタマイズチャンネルを作成し、そ のアプリケーションのアップデートがリリースされたらカスタマイズエラータとして登録配信することも可能です。もちろん、Provisioning Moduleと組み合わせることで、RHELに続いてこれらのアプリケーションのインストールを自動で行うことも出来ます。

　RHN Satellite ServerはEmbedded Oracleデータベース（大規模な場合は外部のOracleデータベースを利用）に、チャンネルやエラータ、RHNアカウント、システムプロファイルなどの管理に必要な全てのデータを保持します。


　 図10　CertKeyの例（実際に利用できるものではありません）


　冗長性を考慮して、複数台のRHN Satellite Serverを同一のサイトに設置することも、あるいはディザスタリカバリー用に遠隔地に設置することも可能です。拡張性だけを考慮するのであれば、１ 台のRHN Satellite Serverでも数千台に及ぶユーザシステムを登録可能です。
　RHN Satellite Server上に追加の設定を行うことで、ベアメタルPXEキックスタートも可能です。PXE（Preboot eXecution Environment）はIntelが開発したネットワークブートの規格です。昨今のサーバ用NIC（Network Interface Card）では、ほとんどがこの規格をサポートしていますので、ネットワークに接続して電源を入れると、自動的にネットワークブートを行うことが可能です。

RHN Satellite Serverは、ネットワーク経由でLinuxのカーネルイメージを提供し、更にキックスタートファイルを配信することで、自動的にネットワークインス トールを行うことが可能です。従って、新たに用意したハードウェアをネットワークに接続し、PXEの選択画面でRHELのバージョン、例えば、Red Hat Enterprise Linux AS (v.4 for 32bit x86)のUpdate4、を選択し、インストール・ウェブサーバ用の設定を行うといったことが、全て自動的に完了できます。

Satellite + Proxy Model


　RHN Satellite Serverの主な機能は３つあります。データベースサーバ（Embedded Oracleを利用する場合）、アプリケーションサーバ、ウェブサーバです。データベースサーバとしては数千台を登録してもそれほどシステムには負荷が かかりませんし、アプリケーションサーバもJavaで実装されているため、メモリ要件を満たしたハードであればそれほど負荷は問題になりません。

しかしながら、管理対象のユーザシステムが増えれば増えるほど、あるいは個別のユーザシステムにインストールされているRPMパッケージが多ければ多いほど、 ウェブサーバとしての負荷は幾何級数的に大きくなります。このため、ユーザシステムが150台を超える毎に1台のRHN Proxy Serverの追加を推奨しています。


　 図11　Satellite + Proxy Model

最後に


　今回と前回の２回に渡ってRed Hatが提供するRed Hat Networkをご紹介いたしました。RHNの機能は非常に多岐に渡り、日本語版のインストールマニュアルやリファレンスマニュアルは、いずれも印刷すると数センチの厚さになる製品です。このため、RHN Satellite Server/Proxy Serverについては、弊社のGlobal Learning Service（GLS）のRH401というトレーニングコースもご用意しております。

RH401コースは、実際にRHN Satellite Serverのインストールからチャネルデータの読み込みや設定チャネルの作成を行う、あるいは管理運用方法の全般についての詳細など、実技中心の構成となっております。是非、このコースもご受講いただき、RHN Satellite Serverを存分に活用していただければ幸いです。コース内容の詳細については以下のURLをご参照ください。
http://www.jp.redhat.com/training/architect/courses/rh401.html

　

Red Hat Magazineのご紹介


Red Hat Magazineとは、米国Red Hat社が毎月発行しているオンラインマガジンです。 日本でも随時記事内容を抄訳して日本のウェブサイトに掲載しております。

【Frysk Monitor】
Fryskの用途の1つは、実行分析ツールとして使用することです。「実行分析ツールとは何か」と疑問に思われるかもしれません。
実行分析ツールとは・・・
続きはこちら↓
　http://www.jp.redhat.com/magazine/NO34/

【キックスタートの使用方法（Anacondaのリモート制御）】
Anacondaは、Fedora ProjectとRed Hat Enterprise Linuxで使用されている、きわめて柔軟なインストールプログラムです。ローカルメディア（ハードドライブ、CD/DVD、USBキーなど）からのイ ンストールのサポートに加えて、Anacondaでは、ネットワークソース（FTP、HTTP、NFSなど）からもインストールできます。また、・・・
続きはこちら↓
　http://www.jp.redhat.com/magazine/NO33/

レッドハット株式会社/ニュースレター編集部