 Print-friendly Version
Sun Java System Web Server 7、Solaris ゾーン、および DMZ のユーザーシナリオPartha Dey (2006 年 11 月) サーバーとソフトウェアコンポーネントの巨大なネットワークを管理するコストが大幅に増大したため、IT インフラストラクチャーのコストを削減して、システムをよりよく管理するための新しい方法の開発に注目が集まっています。サーバーを統合および仮想化する手法は、データセンターの管理を改善するために役立ちますが、アプリケーションをプロビジョニングし、セキュリティーと使いやすさを向上させる、より優れた方法も存在します。これらのリソース管理手法の効果を発揮させるためには、アプリケーションを独立して管理し、ビジネスニーズに応じて資源利用率を制御し、障害を瞬時に特定し、複数のアプリケーション間のセキュリティーを確保できなければなりません。 Solaris コンテナテクノロジの一部である Solaris ゾーンは、OS レベルでこのような環境を実現する、簡単で効率的な手法を提供します。ゾーンを使用することで、どのようにサーバーの仮想化と統合を実現できるのか、および Sun Java System Web Server 7 (以後 Web Server 7 と表記) は、このような環境を使用して、アプリケーションのプロビジョニングと使いやすさをどのように改善できるのかについて説明します。 この記事では、次に示すトピックについて説明します。
Solaris ゾーンとはゾーンは、Solaris 10 OS のアプリケーションおよびリソース管理機能です。この機能により、アプリケーションに対して、分離されたセキュアな仮想 OS 環境、またはゾーンとして、OS を表現できます。ゾーンは、OS の独立性とある程度の集中リソース管理の両方の利点を持っています。このため、特定の OS リソースを中央で割り当てて管理できる一方、アプリケーションを複数のゾーンにインストールして実行することでアプリケーションを互いに分離できます。ゾーン環境の観点から見た OS リソースには、プロセス管理、メモリー、ネットワーク構成、ファイルシステム、パッケージレジストリ、ユーザーアカウント、共用ライブラリ、また、場合によっては、インストールされているアプリケーションなどがあります。 ゾーンを使用すると、Solaris OS の 1 つのインスタンス内で、仮想化されたオペレーティングシステム環境を作成し、1 つ以上のプロセスをシステム上のほかのアクティビティーから分離して実行できます。この分離により、ユーザー ID などの資格情報にかかわらず、特定のゾーン内で実行されているプロセスは、ほかのゾーンで実行されているプロセスを監視したり、そのプロセスに影響を与えたりすることがなくなります。ゾーンは、1 つ以上のアプリケーションがシステムの残りの部分に影響を与えたり、残りの部分と相互に作用したりすることなく実行されるサンドボックスです。また、ゾーンは、物理デバイスのパス、ネットワークインタフェース名、ネットワーク経路指定テーブルなど、アプリケーションが配備されているマシンの物理的属性から、アプリケーションを分離する抽象化レイヤも提供します。 ゾーンのメリットセキュリティー ネットワークサービスをゾーン内で実行すると、セキュリティー違反が発生した場合に起こり得る損害を限定できます。ゾーン内で実行されているソフトウェアのセキュリティーホールをうまく利用した侵入者も、そのゾーン内で可能な限定的なアクションしか実行できません。たとえば、大部分のゾーン内で実行されているアプリケーションは、カスタマイズされているカーネルモジュールをロードしたり、カーネルメモリーを変更したり、デバイスノードを作成したりすることはできません。ゾーン内で使用可能な特権の集合は、システム全体として使用可能な特権の部分集合です。 分離 ゾーンを使用すると、アプリケーションが、複数の信頼ドメイン内で動作し、グローバルリソースへの排他的アクセスや、別個の構成を必要とする場合でも、同じマシン上で複数のアプリケーションを配備できます。たとえば、各ゾーンに関連付けられている個別の IP アドレスを使用して、同じシステム上の異なるゾーンで実行されている複数のアプリケーションを、同じネットワークポートにバインドできます。また、アプリケーションは、互いのネットワークトラフィック、ファイルシステムデータ、プロセスアクティビティーなどを監視したり傍受したりできません。 仮想化 ゾーンは、物理デバイス、システムの主 IP アドレス、およびホスト名などの詳細をアプリケーションから隠せる、仮想化された環境を提供します。仮想化を行うと、同じアプリケーション環境を複数の物理マシンで維持できるので、アプリケーションの迅速な配備および再配備をサポートできます。仮想化された環境は、各ゾーンを別々に管理できるほど充実したものです。管理者が実行するアクションがシステムの残りの部分に影響しないことを把握した上で、ゾーン管理者にルートパスワードを公開することも可能です。このような機能は、システムを社内外の顧客用に細分化するための、より粒度の高い方法を探しているサービスプロバイダにとって魅力的です。 粒度 ドメインや LPAR (Logical Partitioning) などの物理的なパーティション分割技術とは異なり、ゾーンはほぼすべての粒度での分離を実現できます。ゾーンには、専用の CPU、物理デバイス、または大量の物理メモリーは必要ありません。このような資源は、1 つのドメインまたはシステムで実行される複数のゾーンに渡って多重化するか、オペレーティングシステムに用意されている資源管理機能を使ってゾーンごとに割り当てることができます。このため、小型の単一プロセッサシステムでも、同時に動作する多数のゾーンをサポートできます。主な制限は、各ゾーン内で実行されるアプリケーションのパフォーマンス要件を除くと、各ゾーン内で固有のファイルを保持するためのディスク容量です。 透過性 ゾーンの基本的な設計原則の 1 つは、セキュリティーと分離という目標を実現するために必要な場合を除き、アプリケーションが実行されている環境の変更を避けるというものです。ゾーンには、アプリケーションを「移植」する必要がある新しい API や ABI はありません。その代わり、ゾーンを使用すると、いくつかの制限付きで、標準の Solaris OS のインタフェースとアプリケーション環境が提供されます。この制限の影響を主に受けるのは、特権付きの操作を実行しようとするアプリケーションです。 Web Server シナリオでのゾーンの適合性ゾーンの使用は、次に示す目標を実現するために役立ちます。 サーバーの利用または統合、あるいはその両方 ゾーンを使用すると、コンピュータ上で、より効率的な資源の使用が可能です。十分活用されていない専用コンピュータ上で実行されている複数の Web Server インスタンスは、1 台のコンピュータの個別の非大域ゾーンで実行することで、統合できます。大域管理者は、それらのゾーン内で実行されているコンポーネントのリソース要件に応じて、リソースを動的にゾーン間で配分して割り当てることができます。 集中ライフサイクル管理 ゾーンを使用すると、ライフサイクル管理を集中化できます。その他のゾーン内にあるほかのインストールを邪魔することなく、ゾーン内の Web Server をインストール、アップグレード、およびアンインストールできます。複数の非大域ゾーンで実行するコンポーネントは、実行時の分離、セキュリティー、スケーラビリティーと他のニーズを満たせます。たとえば、大域ゾーンに Web Server をインストールして、非大域である別のゾーンで複数のインスタンスを実行することができます。この目標を実現するために、ライフサイクルを大域管理者に管理させ、構成と実行時の管理はゾーン管理者に委任します。 バージョンの分離 Web Server の複数のバージョンの並列セットを複数のゾーンで実行できます。これにより、一定の期間で、ある Web Server のバージョンから別の Web サーバーのバージョンへの移行を実現できます。 組織の独立性 複数の組織は、すべて同じコンピュータ上で共存して実行される、互いに異なる Web Server の配備、またはWeb Server の個別の実行時インスタンスを維持できます。たとえば、複数の開発者グループが、Web Server の独自の個別インスタンスを使用したり、複数の組織がテスト、本稼働前のステージング、または本稼働の各用途に Web Server の異なる配備を使用したりできます。組織の独立性は、特有の目標に応じてさまざまな方法で実現できます。ゾーン管理者に構成と実行時の管理を委任するときにWeb Server のライフサイクル管理を集中化する一方で、または、ライフサイクル、構成、および実行時のすべての管理機能をゾーン管理者に委任する方法があります。 ゾーンのタイプとゾーンの作成方法完全ルートゾーン この特定モデルでは、特定のメタクラスタを構成するゾーンで必要なすべてのパッケージが、大域管理者によって選択されたその他のすべてのパッケージに加えてインストールされます。完全ルート非大域ゾーンを作成すると、大域ゾーンにインストールされているすべてのパッケージがその完全ルート非大域ゾーンで使用可能になります。パッケージデータベースが作成され、すべてのパッケージが非大域ゾーンにコピーされて、すべてのファイルの独立した専用コピーが作成されます。 このモデルには、ゾーン管理者が、 疎ルートゾーン このモデルは、疎ルートという名前が表すように、大域ゾーンに存在するファイルシステムの一部だけの読み取り / 書き込みできるコピーを含み、その他のファイルシステムは、ループバック仮想ファイルシステムとして大域ゾーンから読み取り専用でマウントされます。大域管理者は、疎ルートゾーンの作成時に、疎ルートゾーンと共有するファイルシステムを選択します。デフォルトでは、 完全ルートゾーンと疎ルートゾーンの比較 完全ルート非大域ゾーンと疎ルート非大域ゾーンのどちらを使用するかは、リソースの効率と管理コントロールとの間のかね合いによって決まります。完全ルートゾーンを使用すると、メモリーやその他のリソースを犠牲にして、管理コントロール、つまり独立性と分離の側面を最大化できます。疎ルートゾーンは、実行上の独立性を犠牲にして、はるかに小さなディスク占有量で、実行可能ファイルと共用ライブラリの共有効率を最適化します。現時点では、完全ルートゾーンに対する疎ルートゾーンのパフォーマンス上の利点は、測定手段がなく、ソフトウェアによって決まる場合が非常に多いと言えます。 コマンド行による局所ゾーン (非大域ゾーン) の作成 例: # zonecfg -z <zone_name> <zone_name> No such zone configured Use 'create' to begin configuring a new zone. zonecfg:<zone_name>> create -b (create -b オプションは \Whole Root Zone を作成し、-b オプションがない場合は Sparse Root Zone を作成します。) zonecfg:<zone_name>> set autoboot = true zonecfg:<zone_name>> set zonepath = /<path>/<zone_name> zonecfg:<zone_name>> add net zonecfg:<zone_name>:net> set physical = <network_interface> eg; hme0 zonecfg:<zone_name>:net> set address = <ip_address> zonecfg:<zone_name>:net> end zonecfg:<zone_name>> verify zonecfg:<zone_name>> commit zonecfg:<zone_name>>^d # # zoneadm list -cv ID NAME STATUS PATH 0 global running / - <zone_name> configured /<path>/<zone_name> # # zoneadm -z <zone_name> install # # zoneadm list -cv ID NAME STATUS PATH 0 global running / - <zone_name> installed /<path>/<zone_name> # # zoneadm -z <zone_name> boot # zlogin -C <zone_name> <== ここに言語、契約条件タイプ、ホスト名、NIS など、必要となる入力項目をすべて指定します。 .... SunOS Release 5.10 Version s10_u1wos 64-bit Copyright 1983-2004 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Hostname: <zone_name> NIS domain name is <nis_domain_name> 異なる種類のゾーンでの Web Server 7 のサポートWeb Server 7 のインストールは、次に示すように、さまざまなタイプのゾーンの下でいろいろなシナリオでテスト済みです。
実際の Web Server 7 の代表的な実装ここでは、管理サーバーが外部の世界に対してもっとも保護および制限されるように、ファイアウォールの背後 (Demilitarized Zone、DMZ) で複数のゾーンにノードが構成され、もう一つのファイアウォールの背後 (Militarized Zone、MZ) で管理サーバーが構成されているユースケースのシナリオの例を紹介します。ノードの 1 台は、逆プロキシサーバーとして構成できます。逆プロキシサーバーは、セキュリティーを強化するために、ファイアウォールの外側に配置することも、DMZ の内部に配置することもできます。実際の Web サーバーへのアクセスには、逆プロキシサーバーが使用されます。逆プロキシサーバーは、実際の Web サーバー から Web リソースを検索する際にファイアウォールを介するので、攻撃への脆弱性を大幅に縮小できます。DMZ の内部には 1 台のディレクトリサーバーを配置でき、MZ の内部には 1 台のデータベースサーバーを配置できます。
図 1 MZ (Militarized Zone) 内部:Admin サーバー。MZ 内部にある場合、非公開の登録されていない IP アドレスは 使用されます。 DMZ (Demilitarized Zone) 内部:ノード。上の図の IP アドレスは実際のものではなく単なる例です。 DMZ 領域には、前の例で示されているように、1 つのサーバーに 4 つの異なるゾーンが構成されています。ホスト名とゾーンタイプは次のとおりです。
GZ-2 は、逆プロキシとして構成されるもう 1 台のサーバーです。 複数のインストールおよび構成オプション前述の例では、1 台の Admin サーバーと 1 台以上のノードをインストールして、サーバーファームを作成する必要があります。前述の例では、4 台のノードをインストールしています。 Admin サーバーをインストールする方法 CLI モード:
ライセンス条項のあとで、「カスタムインストール」を選択し、「管理サーバーとしてインストール」を選択します。SSL または SSL 以外のポートを指定する必要があります。 GUI モード:GUI を使用して、Admin サーバーをインストールします。
ライセンス条項、コンポーネントの選択、および Java の構成のあとで、「カスタムインストール」を選択し、「管理サーバーとしてインストール」を選択します。SSL または SSL 以外のポートを指定する必要があります。インストールプロセスを完了します。特定の Java パスを指定することもできます。UNIX で 1.5.0_08、Windows で 1.5.0_07 の J2SE バージョンが最小限必要です。 ノードがサーバーファームの構成要素となるように管理エージェントをインストールする方法 CLI モード:ノードに対して
「カスタムインストール」を選択して、「管理ノードの作成」を選択します。ホスト名とポートを指定します。ノードは、インストール中に Admin サーバーに登録できます。登録プロンプトが表示されたら、ノードを登録するリモート Admin サーバーのホスト名とポートを指定します。 GUI モード:GUI を使用して、管理エージェントをインストールします。
「カスタムインストール」を選択して、「管理ノードの作成」を選択します。ホスト名とポートを指定します。ノードは、インストール中に Admin サーバーに登録できます。登録プロンプトが表示されたら、ノードを登録するリモート Admin サーバーのホスト名とポートを指定します。 Admin サーバーにノードを登録する方法 インストール中にノードを登録していない場合は、インストール後でも、ノードから 管理エージェントのインストール後にノードを登録するには、次のように入力します。 ../wadm --host=<admin-server-host> --port=<admin-ssl-port> \ --user=<admin-user> (パスワードの入力を求められます) wadm> register-node ノードの登録を解除する必要がある場合は、次のように入力します。 ../wadm --host=<admin-server-host> --port=<admin-ssl-port> \ --user=<admin-user> (パスワードの入力を求められます) wadm> unregister-node クラスタ構成の作成 前提条件: サーバーファームが存在すること。上述の手順を使用してサーバーファームを作成してください。 クラスタ内のすべてのインスタンスが同種であること。 仮定: 構成を config1 と呼び、Admin サーバーがあるノードを AS1 と呼び、Admin サーバーに登録されている管理エージェントがあるノードを WRZ-1、SRZ-1、および SRZ-2 と呼ぶことにします。
これで、クラスタ構成の準備が整いました。 セッションのレプリケーション クラスタ化したあとの次に来る重要な手順は、インスタンス内に配備されているアプリケーションのセッションがフェイルオーバーできるように、セッションのレプリケーションを構成することです。セッションのフェイルオーバーの目的は、Web アプリケーションに高い可用性を提供することです。軽量なセッションのフェイルオーバーは、あるインスタンスから同じクラスタの別のサーバーインスタンスに HTTP セッションをレプリケートすることで、この目的を実現します。これで、リモートインスタンス上に各 HTTP セッションのバックアップコピーが作成されます。1 台のノードで障害が発生してクラスタ内の 1 つのインスタンスが使用できなくなることがあっても、クラスタはセッションの継続性を維持できます。
Web アプリケーションの配備
監視 この機能は、次に示す目的のために使用できる、実行時コンポーネントおよびプロセスの状態に関する情報を提供します。
またこの機能は、すべてが予想どおりに機能していることを確認するためにも使用できます。。 ローカルおよびリモートインスタンスの監視データは、
GUI ナビゲーション:「監視」-->「インスタンス」を選択します。 逆プロキシ 前述のとおり、上記のシナリオのノードの 1 台を逆プロキシサーバーとして構成できます。逆プロキシサーバーは、セキュリティーを強化するために、ファイアウォールの外側に配置することも、DMZ の内部に配置することもできます。実際の Web サーバーへのアクセスには、逆プロキシサーバーが使用されます。逆プロキシサーバーは、実際の Web Sever から Web リソースを検索する際にファイアウォールを介するので、攻撃への脆弱性を大幅に縮小できます。URL の書き換えやラウンドロビン方式の負荷分散をはじめとする、基本的な逆プロキシ機能を使用すると、DMZ やその他のサーバー製品を保護するために、サーバーを使用できます。また、NSAPI フィルタと組み合わせると、文字列の置換や圧縮など、プロキシ処理されたコンテンツをさらに処理できます。 前提条件:
1. オリジンサーバーに要求を渡すように、逆プロキシを構成します。HTTP要求は、クライアントによって、RP (Reverse Proxy、逆プロキシ) に対して行われます。RP は、次のように、オリジンサーバーに要求を渡します。 wadm> create-reverse-proxy --configRPConfig --vsRPConfig --uri-prefix / --server http://WRZ-1:3456 2. シンプルな固定アプリケーションに対する要求を複数のサーバーに渡すように、逆プロキシを構成します。この構成では、2 番目の HTTP 要求は最初の要求を処理したのと同じサーバーに移り、2 番目の要求はセッション情報を検索できるはずです。 wadm> create-reverse-proxy --configRPConfig --vsRPConfig --uri-prefix \ / --server http://SRZ-1:3456,http://WRZ-1:3456 GUI ナビゲーション:「構成」-->「インスタンス」-->「 仮想サーバー」-->「コンテンツ処理」-->「逆プロキシ」と選択します。 まとめこの記事が、Web Server 7 の設定に役立つガイドラインになればと思います。また、セキュリティーポリシー、検索コレクション、パターンマッチングの設定などのその他の構成内容については、『Administrator's Guide』を一読してください。 Web Server 7 は多くの新機能を備え、管理機能も全面的に改善されたことで 、さらに有益な製品になっています。Web Server 7 は、現在入手できるこの種の製品の中でも、特にセキュアで安定性が高く、パフォーマンスに優れた設計がなされています。詳細は、Java System Web Server 6.1 SP5 を使用したテスト結果、『Sun Fire T1000 Server with CoolThreads Technology Outperforms All Competing 1U Systems on the Market』を参照してください。 関連リンク
Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License. |
 BigAdmin SubscriptionsBigAdmin Areas
BigAdmin Sun Center
BigAdmin Topics |
 | |
