本文へジャンプ

ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Workplace Collaboration Services > 

LDD Today

WebSphere Edge Server をプロキシーとして Lotus Workplace Messaging 環境にインストールする


 Lotus Software
by
Geno Spinosa, Advisory Software Engineer, IBM
Wendi Pohs, Consulting IT Specialist, IBM
レベル：中級者
原文の掲載：2004年8月3日

LDD Todayの原文（US）

インデックス
プロキシー・サーバー
インストールと構成
フォワード・プロキシーの構成
リバース・プロキシー
透過プロキシー
推奨事項とまとめ

この記事は、WebSphere Edge Server を Lotus Workplace Messaging 環境にインストールして構成し、フォワード・プロキシー、リバース・プロキシー、および透過プロキシーとして機能させる方法について書かれています。

サーバー・セキュリティーについて計画することは、Lotus Workplace Messaging 1.1 または 2.0 をご自分のインフラストラクチャーに導入する際に、たいへん重要なステップとなります。サーバーをロック・ダウンする、最新のパッチをインストールする、または不要なすべてのポートを閉じるといった方法があります。さらに、プロキシー・サーバーを構成することもできます。プロキシー・サーバーを使用すると、社内の環境とインターネット間でトラフィックを制御できます。これらの各機能はそれぞれ専用の目的を持ち、インフラストラクチャーを不正アクセスから保護する役割を果たします。しかし、セキュリティー機能の実装によってサーバー・パフォーマンスを犠牲にすることはできません。また、これらのセキュリティー機能が管理オーバーヘッドを大幅に増加させるようなことがあってもなりません。

この記事では、Lotus Workplace Messaging 1.1 および 2.0 用のさまざまなプロキシー構成で WebSphere Edge Server Version 2.0 に行ったテストの内容を紹介します。この記事のすべての内容は、Lotus Workplace Messaging 1.1 および 2.0 のどちらの環境にも同じように適用されます。ご自分のサイトにプロキシーをインストールする際のネガティブな影響 (導入コストの増加や応答速度の低下など) を避けるために、この記事が役立つことを望んでいます。この記事は、基本的なネットワーク管理とセキュリティー機能についての知識があることを前提として書かれています。


プロキシー・サーバー
ほとんどのビジネス・ネットワークの管理者は、自らの組織のためにプロキシー・サーバーを使用しています。プロキシー・サーバーは、ネットワーク・トラフィックの振り分け、コンテンツのフィルタリング、およびトラフィック・フローの変更を行います。プロキシー・サーバーを使用すると、ユーザーが Web で実行できる操作を決めたり、ユーザー・アクティビティのレポートを作成できます。また、プロキシー・サーバーは、Web 関連情報を保管するキャッシュ・システムによって、システムのパフォーマンス改善に貢献します。

プロキシー・サーバーは、いくつかの方法で導入できます。Lotus Workplace Messaging 1.1 および 2.0 は、次のプロキシー構成をサポートします。
  • フォワード・キャッシュ/キャッシュなし
  • リバース・キャッシュ/キャッシュなし
  • 透過キャッシュ/キャッシュなし
  • ディスパッチャー/ロード・バランサー


フォワード・プロキシー
フォワード・プロキシー (図 1 参照) は、セキュリティー、キャッシュ、およびフィルター用の 1 つのサーバーを介して、複数のクライアントにインターネット・アクセスを提供します。

図 1. フォワード・プロキシー



フォワード・プロキシーは、リクエストをリダイレクトすることによってインターネットへのアクセスを与えます。フォワード・プロキシーは 1 つのマシン上で実行されるので、ユーザーに Web へのダイレクトなアクセスを禁止しながら、自分自身はファイアウォールを介して認証済みゲートウェイとして動作できます。フォーワード・プロキシーは、頻繁にアクセスされるサイトや他の Web 要素を格納するキャッシュとしても機能します。キャッシュによって、パフォーマンスが大幅に向上します。さらに、プロキシー・サーバーは、ポップ・アップや迷惑なコンテンツ、あるいは Web サイト全体をブロックする Web フィルタリング機能を提供します。

リバース・プロキシー
リバース・プロキシー (図 2 参照) は、クライアントの代理として、複数のサーバーへのリクエストをリダイレクトします。

図 2. リバース・プロキシー



リバース・プロキシーを使用すると、他のサーバーからのコンテンツを 1 つの Web サーバーによって提供できます。通常、リバース・プロキシーは、ファイアウォールの裏側にある複数サーバーに対する Web からのアクセスを制御するために使用されます。フォーワード・プロキシーと同様に、リバース・プロキシーもキャッシュによってパフォーマンスを向上させることができます。

透過プロキシーとディスパッチャー (ロード・バランサー)
透過プロキシーは、呼び出し側のクライアントが実際のプロキシーを見ることができない点を除き、フォワード・プロキシーと似ています。ディスパッチャー (ロード・バランサーともいいます) は、ユーザーのワークロードをアイドル状態または使用度の少ないサーバーに振り分けます。

図 3. ディスパッチャー

 
上に戻る
 
インストールと構成
今回のテスト用の構成は、最新の修正パッチを適用した Windows 2000 のもとで行われています。テストに使用したどのコンピューターも、少なくとも次の仕様を満たしています。
  • 512MB のメモリー
  • 1GHz のプロセッサー
  • 10GB のディスク・スペース
今回のテスト用のセットアップでは、フォワード、リバース、透過の各プロキシーをインストールしました。これを行うために、まず、Caching Proxy サーバーをインストールし、次に、目的のプロキシー機能 (フォワード・プロキシー、リバース・プロキシーなど) を実行するようこのサーバーを構成しました。

Caching Proxy サーバーのインストールは、『WebSphere Edge Server 管理ガイド バージョン 2.0 GC88-8737-02（US）』(現在リンク切れ)に記載されている説明に従って行いました。このガイドを使用すると、ご自分の環境に適したインストール方法の説明が得られます。

構成
Caching Proxy をインストールした後、私たちは Caching Proxy サーバーにある ibmproxy.conf ファイルの構成パラメータを変更しました。
  • MaxActiveThreads 100
    これは、アクティブ・スレッド数を 100 に設定します。
  • ConnThreads 15
    これは、接続スレッド数を 15 に設定します。
  • Caching ON
    これは、URL のローカル・キャッシングを有効にします。
  • CacheMemory 85 M
    これは、利用可能な物理メモリー量に応じて、キャッシュ・メモリーを少なくとも 85MB に設定します。
  • CacheFileSizeLimit 4000 K
    これは、利用可能な物理メモリー量に応じて、キャッシュするファイル・サイズの上限を 4MB に設定します。
  • DelveInto always (以下の「探求」の説明を参照)
    これは、キャッシュ・リンクを有効にします。(探求の説明については、次のセクションを参照してください。)
  • elveDepth 1
    これは、キャッシュ・リンクの深さを 1 に設定します。
  • NumClients 100
    これは、システムの処理能力に応じて、クライアントの最大数を 100 に設定します。

探求
探求は、自動キャッシュ更新機能のオプションの 1 つです。ほとんどの Web ページには関連する情報を含む他のページへのリンクがあり、ユーザーはこれらのパスリンクをたどって、ページ間およびサイト間を移動します。探求は、これらの論理的な情報パスをキャッシュする 1 つの方法です。探求では、キャッシュ・エージェントが、ロードしているページ上にあるハイパーテキスト (HTML) リンクを指定された階層 (レベル) だけたどり、リンク先のページをキャッシュします。リンク先のページは、ソース・ページと同じホストにあることも、別のホストにあることもあります。(探求の動作の詳細については、『WebSphere Edge Server 管理ガイド（US）』(現在リンク切れ)を参照してください。)

キャッシュ・サーバーをセットアップした後は、サーバーをフォワード・プロキシー、リバース・プロキシー、および透過プロキシーとして機能させるために、特定の構成を行いました。次のセクションでは、この構成方法について説明します。
 
上に戻る
 
フォワード・プロキシーの構成
Caching Proxy のインストール後、Lotus Workplace Messaging でフォワード・プロキシーとして機能するようプロキシーを調整し、構成する必要があります。これを行うために、C:\Program Files\IBM\edge\cp\etc\en_US ディレクトリーにある ibmproxy.conf ファイルを編集します。プロキシーをフォワード・プロキシーとして機能させるには、次のディレクティブの変更が必要です。
  • PureProxy on
    これは、プロキシーがピュア・プロキシー・モードで動作するよう指定します。
  • Port 80
    これは、非 SSL のリクエストを待ち受けるポートを定義します。
  • Hostname Myhostname.domainname.com
    これは完全修飾ホスト名です。
また、キャッシュ・サーバー用に変更した構成パラメーター (前のセクションに掲載済み) が、フォワード・プロキシーのパフォーマンスの微調整にも有効であることがわかりました。これらのパラメーターを変更した後は、その影響を正しく評価するために、変更の前後におけるパフォーマンスの変化を必ずモニターしてください。

最後に、プロキシー・サーバーを実行するために、テスト用のクライアントで、Microsoft Internet Explorer ブラウザーの設定を変更する必要があります。これを行うには、まず、Internet Explorer を起動し、[ツール] - [インターネットオプション] を選択します。[インターネットオプション] ダイアログボックスの [接続] タブで、[LAN の設定] をクリックします。次に、[LAN にプロキシサーバーを使用する] オプションを選択し、[アドレス] フィールドにプロキシーのアドレスを入力します。最後に、ポート番号の 80 を [ポート] フィールドに入力します。[OK] を 2 回クリックし、ブラウザーの設定を保存します。

プロキシー・ログは、C:\Program Files\IBM\edge\cp\server_root\logs にあります。このログを表示するには、プロキシー・サービスを停止した後で開くか、Wordpad エディターを使用して別のファイル名にコピーします。
 
上に戻る
 
リバース・プロキシー
フォワード・プロキシーと同様に、リバース・プロキシーの構成も Caching Proxy サーバーのインストールから開始します。これが完了した後、Lotus Workplace Messaging でリバース・プロキシーとして機能するよう Caching Proxy サーバーを構成します。最初に、サーバーの C:\Program Files\IBM\edge\cp\etc\en_US ディレクトリーにある ibmproxy.conf ファイルを編集します。Caching Proxy がリバース・プロキシーとして機能するよう、次のディレクティブを変更します。
  • PureProxy on
    これは、プロキシーがピュア・プロキシー・モードで動作するよう指定します。
  • Port 80
    これは、非 SSL のリクエストを待ち受けるポートを定義します。
  • Port 443
    これは、SSL リクエストを待ち受けるポートを定義します。
  • Hostname Myhostname.domainname.com
    これは完全修飾ホスト名です。Proxy /* http://myhostname.domain.com/*
    これは、目的の Lotus Workplace サーバーの名前です。
  • SendRevProxyName YES
    これは、宛先 URL の代わりにプロキシー名を URL として送信します。
また、プロキシーと Lotus Workplace Messaging との間で SSL を有効にするために、次のディレクティブを構成します。(最初に、製品のマニュアルに従って、Lotus Workplace Messaging 1.1 または 2.0 の SSL を有効にしてください。)
  • SSLEnable ON
    これは SSL を有効にします。
  • SSLVersion ALL
    これは SSL プロトコルのバージョン 2 と 3 を有効にします。
  • KeyRing c:\WINNT\key.kdb
    これは、SSL キーが置かれているキーリング・データベースを定義します。
  • KeyRingStash c:\WINNT\ibmkey.sth
    これは、キーリング・データベースのパスワードが存在するキーリング stash を指定します。
さらに、リバース・プロキシーをサポートするよう Lotus Workplace Messaging を設定する必要があります。これを行うには、Lotus Workplace サーバーの wpconfig プロパティー・ファイルで、プロキシー・サーバーの名前を反映するよう WpsHostName 設定を変更します。
 
上に戻る
 
透過プロキシー
私たちは、Lotus Workplace Messaging の透過プロキシーとしても機能するよう Caching Proxy を構成しました。(透過プロキシー・モードは、WebSphere Edge Server 2.0 の Linux バージョンと AIX バージョンでサポートされています。私たちは、AIX 5.1 にインストールしました。)

透過プロキシーは、Linux Red Hat 7.1 (カーネル・バージョン 2.4、glibc 2.2.2 リリース 10) と SuSE 7.1 (カーネル・バージョン 2.4、glibc 2.2 リリース 7) で実行しました。負荷が高い環境では、このディストリビューションの 2.4 カーネルの特定の SuSE 7.1 コンポーネントを置き換えるよう SuSE は推奨しています。現在の SuSE 7.2 ディストリビューションでは、これらの調整が行われています。追加情報については、SuSE の Web サイトを参照してください。

インストール後、opt\IBM\edge\cp\etc\en_US ディレクトリーにある ibmproxy.conf を編集します。プロキシーを透過プロキシーとして機能させるには、次のディレクティブの変更が必要です。
  • PureProxy on
    これは、プロキシーがピュア・プロキシー・モードで動作するよう指定します。
  • TransparentProxy on
    これは、透過プロキシー・モードを有効にします。
  • Port 80
    これは、非 SSL のリクエストを待ち受けるポートを定義します。
  • Hostname Myhostname.domainname.com
    これは完全修飾ホスト名です。
 
上に戻る
 
推奨事項とまとめ
フォワード・プロキシーおよびリバース・プロキシーでは、各ユーザーごとに少なくとも 2MB のメモリーが必要であることがわかりました。メモリー内にキャッシュを設置することが、最も速く効率の良い方法です。しかし、十分な物理メモリーがない場合は、キャッシュをディスクに保存することもできます。キャッシュをディスクに保存する場合は、保存場所が非常に重要です。ページングまたはオペレーティング・システム用のデバイスは使用しない方がよいでしょう。最も良い結果を得るためには、専用の大容量デバイスを使用することを推奨します。私たちは、ファイルとフォルダーは最も遅いことに気づきました。リバース・プロキシーでは、ユーザーごとに約 17MB のメモリーが必要でした。また、Lotus Workplace Messaging 1.1 と 2.0 では、プロキシーを構成する際に、構成内容の違いはないことがわかりました。

現在、ほとんどの大規模サイトでは、サーバー・インフラストラクチャーの一部としてプロキシー・サーバーを導入しています。プロキシーは、ユーザーとインターネット間のトラフィックを制御し、セキュアにするための 1 つの方法です。また、プロキシー・キャッシングはパフォーマンスの向上に寄与します。この記事では、Lotus Workplace 環境にさまざまな種類のプロキシーをインストールし、構成する方法として、私たちの体験を紹介しました。これらの情報が、プロキシーを導入し、管理オーバーヘッドを増加させることなく、高いパフォーマンスを維持することに役立つことを望んでいます。
 
上に戻る
 
リソース
  • WebSphere Edge Server のマニュアル(現在リンク切れ)には、WebSphere Edge Server のインストールと構成に関する情報が記載されています。
  • developerWorks の Lotus 記事『Running iNotes Web Access with reverse proxies and other security features』には、WebSphere Edge Server をリバース・プロキシーとして構成する方法の詳細な情報が記載されています。
  • SuSE の詳細については、SuSE の Web サイトサイトを参照してください。



著者について
Eugene (Geno) Spinosa : Lotus Engineering Test (LET) チームの Common Services Area で Advisory Software Engineer として勤務。1999 年、Iris Associates に参加し、Lotus Discovery Server の最初から FCS まで、チーフ QE エンジニアとして主にタクソノミー (分類機能) の開発を中心に携わる。ソフトウェア業界の技術系企業でいくつかのポジションに就いたことがあり、対象分野は、ネットワーク、オペレーティング・システム、デバイス・ドライバー、高可用性および耐障害システムなど。

Wendi Pohs : IBM の Intranet User Experience Team における Consulting IT Specialist であり、IBM Press から刊行されたナレッジ・マネージメント手法の書籍『Practical Knowledge Management: The Lotus Knowledge Discovery System』の著者。1996 年、Lotus Development Corporation に入社し、仕様に関するライター、オンラインヘルプ設計者、ユーザー・アシスタント・マネージャーとして数々のプロジェクトに携わる。それ以前は、American Mathematical Society および Digital Equipment Corporation にて勤務。ミシガン大学で BA および MILS の学位を取得。
 
上に戻る