TOP
＞
サーバ構築・運用
＞ システムの更新
徹底入門!! Red Hat Network
第２回：なぜRed Hat Networkを選ぶのか
著者：
レッドハット 藤田 稜
2006/11/28
前のページ
1
2
3
次のページ
システムの更新
エッジサーバから採用が広まったLinuxですが、Webサイトや電子メールがビジネスの遂行になくてはならないインフラとなった昨今、これらのサーバが停止したり攻撃されたりするという状況は頭の痛い問題です。管理者はセキュリティの脆弱性が発見されるといち早く問題に対応しなければなりませんが、管理対象のサーバが多くなるとエラッタの適用だけでもかなりの労力が必要となります。
また、ミッションクリティカルなシステムにおいては、下はハードウェアから上はカスタマイズされたソフトウェアまでを含む自社の「スイート」での十分なテストが必要です。スイートが大きくなれば当然テスト項目も膨大なものとなり、エラッタをリリース直後に適用することは事実上不可能といえます。
しかしRHNを利用する場合は、サーバに配布されるRPMパッケージのバージョンをコントロールする、あるいは「Webサーバグループ」に所属する「1,000台のサーバ」ですら、ただ1回のエラッタ適用作業で更新することが可能になります（図1）。
図1：グループ化して管理することが可能
しかも確認テスト完了後、本番環境にエラッタを適用する際にかかる時間も大幅に短縮することが可能です。システム更新にかかる時間を短縮することは、セキュリティの脅威にさらされている時間の短縮につながるため、目に見えない形ではありますがコストの低減につながります。
設定ファイルの管理
インターネットで検索するとすぐにわかることですが、個人WebサイトやLinux系の情報を掲載しているWebサイトの、地味ではあるけれども確かに需要のある人気コンテンツの1つに、Linuxの様々な設定方法をまとめたものがあります。また、世の解説本の多くも設定方法の説明に多くの紙面を費やしているのが事実です。
一度設定してしまえば、そのサーバについての作業は終了しますが、提供するサービスが変更されれば設定内容を変更する必要がありますし、サービスの拡大に伴ってスケールアウトする場合には、同じ設定を新しいハードウェア上のOSに施さなければなりません。これは解説サイトや書籍の需要がなくならない理由として十分だと考えられます。
まるごとハードディスクをバックアップしてしまうという手法も考えられますが、RPMパッケージによって提供されている、ユーザが変更することのないバイナリやデフォルトの設定ファイルまでバックアップするのもいささかナンセンスな話です。
また設定ファイルによっては、ホスト名やIPアドレス、ネットワークインターフェースのMACアドレスなど、ホスト固有の情報を含んでいることがあります。よって、あるサーバの設定ファイルをそのまま別のサーバにコピーするとトラブルの種になることがあります。
RHNを利用すると、RPMパッケージだけではなく設定ファイルの管理も可能になります。あるサーバ上で設定ファイルを編集し、トライ＆エラーを行った後にRHNセントラルサーバあるいはRHN SatelliteServerにアップロードすることや、アップロードされたファイルをWebブラウザ上で編集することも可能です。
変更された設定ファイルは新しいバージョンナンバーが付与されるため、バージョン同士の比較や、以前のバージョンの設定ファイルでサーバ上の設定を上書きすることも可能です。また、サーバ固有の情報を含む設定ファイルを配布する必要がある場合には、マクロを使って配布時に自動的に文字列が置換されるようにすることもできます。
図2：Config Channel（DNS Serverの設定ファイルを管理している例）
（画像をクリックすると別ウィンドウに拡大図を表示します）
前のページ
1
2
3
次のページ
著者プロフィール
レッドハット株式会社 藤田 稜
レッドハット株式会社 プリセールスエンジニア
ホスト・オフコンのSIer、WebのSIerを経て様々なOSに触れた結果、これからはLinuxだという確信を持ち2005年4月より現職。レッドハットのOEMパートナーやエンドユーザからの導入検討段階での技術的問題の解決、セミナーなどにおけるRed Hat Enterprise Linuxの技術情報の普及に努める。
INDEX
第2回：なぜRed Hat Networkを選ぶのか
Red Hat Networkはシステム管理をどう変えるのか
システムの更新
パフォーマンスのモニタリング
