 |
||||||||||||
|
||||||||||||
| 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| 必要に応じて選択可能なモジュール | ||||||||||||
|
前回はRed Hat Network（RHN）によって何が可能になるのかを、システムのライフサイクルにそって紹介しました。なぜRHNがユーザにとって必要なのかが、理解できたのではないかと思います。しかし実際に導入する際には、システム要件を的確に捉えて最適なRHNの構成を選択する必要があります。 この観点でもRHNは優れた設計があります。「Modularity」つまり「必要に応じて選択可能なモジュール」という考え方です。まず、個別のモジュールを紹介する前に具体的な事例を見てみましょう。 |
||||||||||||
| 典型的なエッジサーバでの事例 | ||||||||||||
|
あるデータセンターでは、2/4wayのラックマウントサーバを中心にブレードサーバを含む百数十台のシステムによって、オンラインショッピングサイトを運用しています。 ビジネスとしては非常に成功しており、毎月数台、多い月には10台を超えるサーバが追加されていました。当然、毎月のように既存のWebサーバやメールサーバと同じ設定のサーバを構築する作業が発生しますし、既存のサーバに対しても自社開発のショッピングプログラムが確実に動作することをテストしてから、セキュリティエラッタを適用していく必要がありました。 このケースに対応するソリューションとして、RHN Satellite Server／Proxy ServerとProvisioning／Management／Monitoring Moduleを導入しました。それぞれ表1のような機能があります。
表1：エッジサーバでの事例と対応するRHNの製品群  図1：グループごとにエラッタ（RPMパッケージ）が適用可能 この事例の場合ではRHNの製品群をすべて用いていますが、システム要件にあわせて4つのモジュールを適切に組み合わせ、Linux（RHN Satellite ServerがあればSolarisも）の管理をRHNに集約することが可能です。次にそれぞれのモジュールについて解説していきます。 |
||||||||||||
|
1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
