 |
||||||||||||
|
||||||||||||
| 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| はじめに | ||||||||||||
|
前回はRed Hat Network（RHN）のモジュールについてご紹介いたしました。Management Moduleによって数十台、数百台のサーバをグループ化して管理することができ、システムの追加はProvisioning Moduleによって自動化し、運用がスタートしたらMonitoring Moduleで監視するという流れはご理解いただけたかと思います。 ここで、想像してみてください。あるユーザは20,000台のRed Hat Enterprise Linuxを管理しています。さて、どのようにエラッタを適用して運用すればいいのでしょうか。 Updateの際には、本連載で解説したように200以上のRPMパッケージがリリースされます。このすべてを更新するということは稀ですが、仮にここでは200MBのデータに相当するとしましょう。「200MB×20,000台」ですから4,000,000MB、つまり4TBのデータをダウンロードする必要が発生します。 これは非常に不経済なことです。なぜなら、あるサーバがダウンロードしたRPMパッケージは、すでに隣のサーバがダウンロードしているかもしれないからです。また、20,000台がすべてインターネットにアクセスできるということも珍しいでしょう。通常、データベースやアプリケーションサーバはバックセグメント、つまりインターネットと接続できないようにすることがセキュリティの観点から考えれば望ましい環境だからです。 最終回の今回は、このような問題に対応するソリューションとして、RHN Satellite Server/Proxy Serverを紹介します。 なお、米国でのRHN Satellite Serverの最大の事例は、17,000台のユーザシステムで構成されており、20,000台という数字は決して誇張したものではありません。 |
||||||||||||
| 選択基準 | ||||||||||||
|
最初に判断しなければならないのは、セキュリティの問題です。もし非常にクリティカルな情報を扱うシステムの場合、RHN Satellite Serverは以下の理由により必須だといえるでしょう。 |
||||||||||||
| インターネットに接続しない（できない） | ||||||||||||
|
外部ネットワークからの攻撃を考慮しなくてもよいということは、セキュリティ上、大きなアドバンテージです。しかし、RHNセントラルサーバと通信する必要があるHostedモデルではインターネットへの接続が必須要件ですので注意が必要です。 |
||||||||||||
| セキュリティアップデートは適用しなければならない | ||||||||||||
|
内部LAN、あるいはローカルユーザからの攻撃を考慮すれば、外部ネットワークに接続しないからといって、セキュリティアップデートを適用しなくてよいということではありません。ユーザに悪意がなくても、Winnyなどのソフトによって偶発的に外部に情報が漏洩する可能性は排除できないからです。 |
||||||||||||
| システム規模 | ||||||||||||
|
次に判断する必要があるのは、システムの規模です（図1）。  図1：サーバの台数で見る各配置モデル・モジュールの選択基準 （画像をクリックすると別ウィンドウに拡大図を表示します） 図1からもわかるように前回紹介したモジュールを利用する場合、サーバの台数は50台前後が採用判断の境目といえます。またManagement Moduleはサーバの台数が50台より少ない場合でも、システムごとにそれほど差異がなければ導入することで管理・運用の大幅な省力化がはかれます。例えば、ロードバランサの下位に同じ構成のWebサーバが10数台あるようなシステムが典型的な例です。 以降では、様々なケースを想定したモデルを紹介していきます。 |
||||||||||||
|
1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
