特集
2004/04/05 10:00 更新

第八回
SharePoint Portal Server導入の実際 (2/2)


サーバファームによる可用性の向上

　SPSを実際に導入し、運用を開始すると、日々膨大な処理要求がサーバに集中することになる。ポータルサイトを提供するサーバとは、利用者が何か作業を始める際の入り口＝ポータルであるがゆえに、サービスダウンや処理スピードの低下は致命的だ。さらに、Webベースのポータルサイトを社内で運用するとなると、パフォーマンスの問題を無視するわけにはいかない。

　一般にパフォーマンスを確保するために取る対策として、サーバの台数を増やし、処理能力を向上するスケールアウトが挙げられるだろう。しかし、部署、部門といった組織の構成単位ごとにポータルを分散させてしまうと、組織全体で統一したポータルの提供や一括管理が難しくなる。

　SPSはサーバファーム構成に対応しているため、組織の規模やビジネス形態の変化に応じて自由に拡張できる、非常に柔軟なスケーラビリティを実現する。例えば、ポータルサイトとなるWebサイトをロードバランサによって負荷分散を実現したり、サーバのクラスタリングを行うなど、システムの可用性を高める堅牢なシステムを構築し、それをサーバファームとして構成することができる。さらにサーバファームに登録した各サーバが、SPSが提供するサービスのうちどのコンポーネントを担当するのかを細かく指定することも可能だ。こうしたサーバの分担処理の管理も、Webベースの管理画面から簡単に行える。

PH01.gif

画面1■サーバトポロジとコンポーネント割り当ての構成画面。Webサーバや検索用サーバを割り当てることができる。


　SPSのインストールが完了すると、自動的にサーバファームの構成画面に遷移する。すでに分散処理を計画し、データベースサーバやインデックスサーバが用意されているのであれば、インストールに続けて処理分担を指定するだけで、分散構成が実現する。予め、システム内で冗長構成を組んでいない場合でも、上のコンポーネント割り当ての設定画面から、いつでも割り当てるサーバを変更することができる。

　SPS を構成するサーバには、「サーバトポロジとコンポーネント割り当ての構成画面」によって、次のような役割を与える。

  • Web サーバ
  • 検索サーバ
  • インデックス サーバ
  • ジョブサーバ
  • Document Managementサーバ（Web Storage Systemベースのドキュメントライブラリを使用する場合）

　これらの機能は、一台のサーバにつき一つの機能ではなく、多対多として構成できる。つまり、Webサーバと検索サーバ、インデックスサーバとジョブサーバといった複数の機能を一台のサーバに割り当てる。または、一つの機能を複数のサーバによって構成することもできるのだ。そのほかにも、サイト構成情報を格納するデータベースとサイトのコンテンツ情報を管理するデータベースを、それぞれ別のサーバに配置することも可能だ。

　分散構成の設計は、一般に利用シナリオや時間経過による利用者の増減、サーバコンピュータのスペックや台数を綿密に吟味し、正確なキャパシティプランニングを行う必要がある。さらに事前に十分に計算された構成でも、予想を超えるアクセス数が発生したり、データ量が急増したときに簡単に拡張することは難しいものだ。SPSなら、ポータルを利用する社員が増加するに伴ってWebサーバにアクセスが集中し、結果としてパフォーマンス低下が心配されるような場合でも、状況に応じてフロントエンドのWebサーバを増強し、常に一定以上のパフォーマンスを得られることになる。

Zu03.gif

図3■一台のサーバがWebサーバ、検索サーバ、インデックスサーバとして機能し、もう一台のデータベースサーバで構成された例。小規模なシステムに適した構成だ。


Zu04.gif

図4■各機能を複数のサーバによって担う最大構成の例。大規模システムや、サービスダウンが許されないミッションクリティカルなシステム向きの構成だ。


　これは情報システム部門の担当者にとって、非常に心強い機能だ。なぜなら、システム導入時に見込んでいたアクセス数を上回る利用があった場合など、システム運用計画を見直さなくてはならないようなケースでも、後からパフォーマンスが低下した部分にサーバを追加するだけで、すばやく、効率的にポータルを強化できるからだ。パフォーマンスの問題だけではない。何らかの原因で、サーバファームを構成するサーバに障害が発生してサービスが停止した際にも、他のサーバを代替サーバとして指定し、サービスの提供を持続することが可能だ。統一された管理画面によって、安定したパフォーマンスと可用性を確保した、信頼性の高いシステムを維持できるのだ。さきほど、トップダウン方式のシステム導入がより一般的と述べた。その場合、導入前に行う設計が、使えるシステムを作り出せるかどうかを決定する非常に重要なプロセスとなるため、事前調査および検討にかなりの時間と手間をかける必要がある。しかし、SPSは導入後の拡張が非常に容易なため、システム設計時おけるシステム管理者の負担を相当に軽減できるのだ。

　SPSが、柔軟にアーキテクチャを更新したり、現状に合わせてシステム構成を最適化できることによって、将来的な利用者やサービスの増加にも迅速に対応できる。SPSの導入は、情報システム部門の管理者や設計者にとっても朗報と言えるだろう。

佐々木 優美子

関連記事
▼なぜSharePoint Portal Server 2003を導入するのか（後編）
▼なぜSharePoint Portal Server 2003を導入するのか（中編）
▼なぜSharePoint Portal Server 2003を導入するのか（前編）
▼Microsoft Office SharePoint Portal Server 2003の全貌を知る

前のページ | 1 2 | 　　　　　

[佐々木 優美子，ITmedia]

Copyright © ITmedia, Inc. All Rights Reserved.