コンテキスト
すでに MOSS をスタンドアロン構成で導入した組織では、利用に伴い、コンテンツの量が多くなってきます。
また、新規の導入であっても、ある程度の計画がされている場合は、そこそこ多くのコンテンツが想定されます。サーバーに関しては、スケールアップではなく、スケールアウトを考えるケースも想定されてきました。
問題
スタンドアロン構成では、データベース ファイルを含め、丸ごとバックアップをしますが、コンテンツの量が大きいと、バックアップ量も多くなります。また、一部の機能が修復不能になるだけで、サーバー全体を復旧する必要も出てきます。
アプリケーション機能とサーバー性能の観点では、データベースはディスク アクセスの速度とディスク耐性について関心の高いものとなりますが、アプリケーション機能は CPU およびメモリ量に関心が集まります。アプリケーションとデータベースでは、サーバーリソースの特性が異なるため、経済性の高い拡張性を考えると、それぞれに特化したハードウェアに分ける必要があります。
もともとデータ ファイル (システム ファイルではない) の量が少ない Web ブロントエンド機能は、より軽量な仮想サーバー イメージとして保持しておくことが望ましいとも言えます。
このように、サーバー役割ごとにシステムを維持する要件が明確に異なってきます。
フォース
解決策
MOSS のスタンドアロン構成から、データベースを分離します。
データベースを分離することで、アプリケーションとデータストアという、性能要件およびセキュリティ要件が大きく異なるコンポーネントを分割します。これは、冗長化構成を考える第一歩となります。
また、一つのデータベース サーバーを複数部門の複数ファームで共用することもできます。
なお、Web アプリケーション サーバーとデータベース サーバーは、異なるセグメントにおいても構いません。
コメント