第3号(2006年12月)

Red Hat Network Part1

“Red Hat Network”について

　まず皆さんの理解を容易にするために、”Red Hat Network”という表現の定義をしておきましょう。一般的にRed Hatがこの表現を使う際には以下のいずれかの意味になります。

(1)サポートポータルであるRHNセントラルサーバ（https://rhn.redhat.com/）
(2)Moduleや配置モデルで構成されるシステム管理製品群
(3)Red Hatのエコシステムのブランド

今回と次回に渡って言及するのは主に(2)のシステム管理製品群についてですが、(1)の場合には「RHNセントラルサーバ」という用語を用います。

１、RHNの利用

　通例レッドハットと製品をご購入されるお客様が結ぶ「サブスクリプション契約」には以下の項目が含まれます。

・テクノロジー：製品とドキュメント、サブスクリプション有効期間内の知的財産権の保証、H/W・S/Wの動作検証と動作保証
・メンテナンス：セキュリティ・バグ修正などを含むエラータの提供
・アップグレード：追加コストなしで最新のリリースを利用可能
・サポート：最大で24時間×365日、無制限のインシデントサポート

　Red Hat Enterprise Linux（以下、RHEL）のサブスクリプション契約のあるお客様は追加コストなしで、全てのバージョン・アップデートのCD-ROMイメージファイ ルを、RHNセントラルサーバからダウンロードすることが可能です。


　図１　Software Downloadsページ
　上述の４つの項目のうち最も頻繁にお客様が利用するものはメンテナンスです。これを提供するRHNセントラルサーバこそがRed Hatのサービスモデルの核であると言うことができ、お客様には是非RHNを積極的にご利用頂き、サブスクリプション契約のメリットを最大限にご活用い ただきたいと考えています。

２、RHNはパッチ配布サーバではない

　RHNというと、一般には「ああ、Red Hatのパッチを配布しているサイトね」というのが皆さんの認識かもしれません。あるいは「画面右上に表示されるびっくりマークでしょ？」とおっしゃる 方も多いことでしょう。


　図２　Red Hat Network Alert Notification Tool
　これだけでなくRHNには

・管理者が日々従事する退屈なサーバ更新作業
・CIOの頭を悩ます不安定なシステム
・CFOがチャレンジしなければならない右肩上がりの運用コストの削減

といった、お客様が直面する様々な問題を解決するヒントが含まれています。まずは「エラータ」からご紹介しましょう。

３、エラータ

　Red Hatでは個別パッチを配布していません。Red HatはRPMパッケージという実行プログラムや設定ファイルなどを１つにまとめたファイルをRHNセントラルサーバから配布します。つまり、パッチを 適用したRPMパッケージを配布するというスタイルです。しかし、あるパッチが複数のRPMパッケージに影響する場合があるので、それらをまとめてエ ラータと呼んでいます。

　図３　パッチ、ファイル、パッケージ、エラータの関係

また、エラータはその内容によって以下の３つに分類できます。

・RHSA（Red Hat Security Advisory）：セキュリティ修正のエラータ
・RHBA（Red Hat Bug Fix Advisory）：バグ修正のエラータ
・RHEA（Red Hat Enhancement Advisory）：機能強化・追加のエラータ

４、OSとアプリケーションの完全なライフサイクル管理

　エラータを配布するのはRHNセントラルサーバの機能の１つですが、RHNが目標としているのは「OSとアプリケーションの完全なライフサイクル管 理」であり、その観点に立って設計された統合フレームワークと言う事が出来ます。
RHNを構成するのは以下の製品群です。

・モジュール：Update、Management、Provisioning、Monitoring
・サーバ：Red Hat Network Satellite Server、Red Hat Network Proxy Server

これらの製品を必要に応じて組み合わせることで、ミッションクリティカルなシステムや10,000台を超えるサーバで構成されるシステムを効率よく安全 に運用・管理することが可能になります。

５、ソフトウェアに関することは全て

　ここまでで、RHNは「OSとアプリケーションの完全なライフサイクル管理の統合フレームワーク」とご紹介しました。次に、RHNの管理対象とするこ とが出来る項目の例です。

・RHELに含まれる全てのRPMパッケージ
・カスタムコンテンツ（サードパーティ製のアプリケーション、エラータ等）
・設定ファイル＝テキストファイル
・サーバのハードウェアプロファイル

RHNはこれらの情報をデータベースに格納していますが、単にRPMパッケージがダウンロードが出来るようになるということを意味するだけではありませ ん。では何が可能になるのかを、システムのライフサイクルに沿ってご説明しましょう。

６、新規システムのインストール

　CD-ROMなどのメディアを使ってOSをインストールするというモデルは、RHELを含むLinuxにおいては過去のものと言えるかもしれません。 高速なLANが低コストで利用できる現在、ネットワーク経由の方がメディアからインストールするよりも時間がかからないことさえあります。しかしメディ アを入れ替える手間が無くなっても、OSのインストール後に管理者を待ち受けるのは、

・最新のエラータを適用
・ドライバやミドルウェアの追加インストール
・サードパーティや自社で開発したアプリケーションのインストール
・現場で作成したマニュアルに沿って各種設定を行う

という、退屈だけれどもミスの許されないルーチンワークです。戦略的なIT投資という観点に立った場合、高度なスキルを持つ技術者を、単純作業ではなく より生産性に直結する業務に従事させる、つまりコストを浪費するのではなく利益を生み出すIT部門に転換させることが必要です。
　RHNによって、新規インストールやそれに続く設定、あるいは既存のシステムと全く同じ設定の追加システムを構築することが自動的に出来るようになり ます。従って、IT部門は、より高度なアプリケーションの開発やコストの低減に役立つ新技術の習得などにリソースを配分できるようになります。

７、システムの更新

　エッジサーバから採用が広まったLinuxですが、ウェブやメールがビジネスの遂行に無くてはならないインフラとなった昨今、これらのサーバが停止し たり攻撃されたりするという状況は頭の痛い問題です。管理者はセキュリティの脆弱性が発見されるといち早く問題に対応しなければなりませんが、管理対象 のサーバが多くなるとエラータの適用だけでもかなりの労力が必要とされます。
　また、よりクリティカルなシステムにおいては、下はハードウェア、上はカスタマイズされたソフトウェアまでを含む自社の”統合システム”での十分なテ ストが必要です。スイートが大きくなれば当然テスト項目も膨大なものとなり、エラータをリリース直後に適用することは事実上不可能です。
　RHNによってサーバに配布されるRPMパッケージのバージョンを管理する、例えば「webサーバグループ」に所属する「1,000台のサーバ」をた だ1回のエラータ適用作業で更新することも可能になります。また「テストグループ」を作成して先行テストを行い十分な確認がなされたのち、「本番グルー プ」にエラータを適用する際に必要な時間も大幅に短縮することが可能です。このことは、セキュリティの脅威にさらされている時間の短縮につながるため、 目に見えない形ではありますがコストの低減につながります。

　図４　グループ化して管理することが可能

　

８、設定ファイルの管理

　インターネットで検索するとすぐに分かることですが、個人サイトやLinux系の情報を掲載しているサイトの、地味ではあるけれども確かに需要のある 人気コンテンツの１つに、Linuxの様々な設定方法をまとめたものがあります。また、解説本の多くも設定方法の説明に多くの紙面を費やしています。一 度設定してしまえば、そのサーバについての作業は終了しますが、提供するサービスが変更されれば設定も変更する必要がありますし、サービスの拡大に伴っ てスケールアウトする場合には、同じ設定を新しいハードウェア上のOSに施さなければならず、解説サイトや書籍の需要が無くならない理由を説明するのに は十分だと考えられます。
　まるごとハードディスクをバックアップしてしまうことも考えられますが、RPMパッケージによって提供され、ユーザが変更することのないバイナリやデ フォルトの設定ファイルまでバックアップするのもいささかナンセンスな話です。また設定ファイルによってはホスト固有の情報を含んでいることもありま す。例えば、ホスト名やIPアドレス、ネットワークインターフェースのMACアドレスなどが相当しますが、あるサーバの設定ファイルをそのまま別のサー バにコピーするとトラブルの元になりがちです。
　RHNによって、RPMパッケージだけではなく設定ファイルの管理も可能になります。あるサーバ上で設定ファイルを編集して、トライ＆エラーののち RHNセントラルサーバあるいはSatellite Serverにアップロードすることも可能ですし、アップロードされたファイルをウェブブラウザ上で編集することも可能です。変更された設定ファイルは 新しいバージョンナンバーが付与されるため、バージョン同士の比較や、以前のバージョンの設定ファイルでサーバ上の設定を上書きすることも可能です。ま た、サーバ固有の情報を含む設定ファイルを配布する必要がある場合には、マクロを使って配布時に自動的に文字列が置換されるようにすることも可能です。

図５　Config Channel -DNS Serverの設定ファイルを管理している例-

９、パフォーマンスのモニタリング

　ここまでご紹介した機能によってサーバの新規配置や設定の管理については、かなり省力化できることがおわかりいただけたかと思います。実際にサーバが 運用開始され、幾度かの設定変更を行いつつ安定運用フェーズに入るかと思いきや、管理者がぶつかる次の壁は、サービスの拡大に伴うパフォーマンスの低下 です。
　サーバ市場やインターネット商取引の急成長は今さらの説明を必要としないと思いますが、それらの数字が物語るもう１つの側面は、個々のサーバにも「負 荷の急成長」が訪れる可能性があるということです。
　一般にサーバのユーティライゼーション（利用率）は80%が理想であるとされています。これより高くなるとサーバの故障率が急激に上昇し、これより低 いとコスト対効果という観点からあまり望ましい状態ではないとされています。サーバの管理者としてはハードウェアのスペックアップの適切なタイミングを 知ることが出来れば、急激な負荷上昇に慌てて対処する必要もなくなります。またコスト管理の観点からは、費用対効果を最大化することで、利益を拡大する ことが可能になります。 　RHNによって、Linuxの様々なヘルスチェックデータや、OS上で動作するアプリケーション、Oracle DBやApacheのステータス情報などを収集してデータベースに格納し、任意の期間を設定してレポートやグラフを生成できます。また、閾値（上限値・ 下限値）を設定することで、エラーを管理者に通知することも可能です。

図６　モニタリングモジュールのレポート

１０、システムを別の目的で再配置する

　システムの運用が長期に渡ると、ハードウェアの入れ替え作業が発生することがあります。例えばそれまでDBサーバとして使っていたハードウェアをアプ リケーションサーバに転用する、あるいは、サービス開始時に想定したよりもメールサーバの負荷が軽く、むしろウェブサーバに振り替えた方が良いといった 状況です。もちろん、それらのサーバを「新規に」インストールすることも考えられますが、長期の運用の間にRPMパッケージは更新されていますし、設定 も変更されている可能性が高くなります。もし既存のサーバを新たなハードウェアに簡単に再現できれば、管理者の作業は大きく軽減されることになります。
　RHNは、こういったニーズにも応えられます。つまり、既存のサーバのプロファイルをベースにキックスタート（自動インストール）することで、全く同 じ構成のサーバを短時間で構築することが可能となります

　 　次回は
　様々なニーズに応えることが可能なRHNの４つのモジュールと、システムの規模や地理的な条件によって最適な配置モデルを選択可能なRHN Satellite/Proxy Serverについて、詳細をご紹介いたします。

---

Red Hat Magazineのご紹介

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

【Enterprise 2.0：流行の言葉、真の革命】
Webの時代には、「2.0」という言葉が意味するところは1.0です。2004年にO'Reillyによって導入された「Web 2.0」という概念は、広範囲のものを含ん でいます。この言葉が新奇で革新的であるとみなされたものすべてに適用されるようになるまで、それほど時間はかかりませんでした。 新しければ、それは2.0でした。 実は、・・・
続きはこちら↓
　http://www.jp.redhat.com/magazine/NO32/

---

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