| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris 11 パッケージリポジトリのコピーおよび作成 Oracle Solaris 11 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris 11 パッケージリポジトリのコピーおよび作成 Oracle Solaris 11 Information Library (日本語) |
このセクションでは、次のメリットを得るために Web サーバーインスタンスの背後で集積サーバーを実行することについて説明します。
コンテンツキャッシュおよび負荷分散によってパフォーマンスを向上します
1 つのドメイン名で複数のリポジトリのホスティングを可能にします。
キャッシュプロキシの背後に集積サーバーを設定するには最低限の構成が必要です。後で説明するカタログ属性ファイルとリポジトリ検索結果を除けば、提供するすべてのファイルは固有であるため、必要な場合は無制限にキャッシュしても安全です。また、キャッシュ内のファイルが誤って無効にならないようにするために、すべての集積応答には適切な HTTP ヘッダーが含まれています。
Apache をキャッシュプロキシとして構成することについては、Apache の Caching Guide を参照してください。
CacheRoot ディレクティブを使用して、キャッシュされたファイルを格納するディレクトリを指定します。指定されたディレクトリが Apache プロセスによって書き込みできることを確認してください。Apache がこのディレクトリに書き込みできない場合、明示的なエラーメッセージは出力されません。
CacheRoot /tank/proxycache
Apache では、特定のディレクトリについてのキャッシュを有効にできます。次のディレクティブに示すように、リポジトリサーバーはおそらくサーバーのすべてのコンテンツをキャッシュすることが必要になります。
CacheEnable disk /
CacheMaxFileSize ディレクティブを使用して、キャッシュするファイルの最大サイズを設定します。Apache のデフォルトである 1M バイトは、ほとんどのリポジトリで小さすぎる可能性があります。次のディレクティブでは、キャッシュするファイルの最大サイズを 1G バイトに設定します。
CacheMaxFileSize 1000000000
基礎となるファイルシステムについて最適なパフォーマンスを得るには、ディスク上のキャッシュのディレクトリ構造を調節します。ZFS データセットでは、ディレクトリレベルが複数ある方が、1 つのディレクトリ内のファイル数よりもパフォーマンスに影響を及ぼします。したがって、ディレクトリレベルを 1 つにして、各ディレクトリ内に多数のファイルを持たせるようにします。ディレクトリ構造を制御するには CacheDirLevels および CacheDirLength ディレクティブを使用します。CacheDirLevels を 1 に設定します。CacheDirLength の値は、ディレクトリ数とディレクトリあたりのファイル数がうまく均衡するように設定します。次のように値を 2 に設定すると、4096 個のディレクトリが生成されます。詳細については、Apache の Disk-based Caching のドキュメントを参照してください。
CacheDirLevels 1 CacheDirLength 2
リポジトリカタログ属性ファイル (catalog.attrs) には、リポジトリカタログの現行ステータスが含まれています。このファイルは、キャッシュを正当化するほどの十分な大きさになることがあります。ただし、バックエンドリポジトリのカタログが変更されると、このファイルは無効になります。次の 2 つの方法のいずれかを使用して、この問題に対処することができます。
このファイルをキャッシュしません。この対処方法は、追加トラフィックが重要な考慮事項とならない高帯域環境においてリポジトリサーバーが実行する場合に最適です。次に示す httpd.conf ファイルの一部は、catalog.attrs ファイルをキャッシュしないことを指定する方法を示しています。
<LocationMatch ".*/catalog.attrs">
Header set Cache-Control no-cache
</LocationMatch>バックエンドリポジトリのカタログが更新されるたびにこのファイルをキャッシュから除去します。
パッケージリポジトリを検索すると、要求に基づくカスタム応答が生成されます。したがって、検索結果はキャッシュにあまり適していません。集積サーバーは、検索結果がキャッシュ内で無効にならないように適切な HTTP ヘッダーを設定します。ただし、キャッシュ作成からの帯域幅の節約量は小さいことが予想されます。次に示す httpd.conf ファイルの一部は、検索結果をキャッシュしないように指定する方法を示しています。
<LocationMatch ".*/search/\d/.*">
Header set Cache-Control no-cache
</LocationMatch>
pkg(5) 集積サーバーによって、ローカルネットワーク内またはインターネット上のリポジトリへのアクセスを簡単に提供できます。ただし、集積サーバーは、1 つのドメイン名または詳細なプレフィックスで複数のリポジトリを提供することをサポートしません。1 つのドメイン名で複数のリポジトリをホストするには、Web プロキシの背後に集積サーバーを実行します。Web プロキシの背後に集積サーバーを実行すると、複数の集積の間での負荷分散を有効にしたり、コンテンツキャッシュを有効にしたりすることによって、サーバーのパフォーマンスを向上することもできます。
このセクションの例では、Apache Web サーバーをプロキシソフトウェアとして使用します。Oracle Solaris 11 OS には、Apache Web サーバーと基本的な httpd.conf ファイルが含まれています。これらの例で示す原則を、任意のプロキシサーバーソフトウェアに適用できるようにする必要があります。
次の設定はパフォーマンスとセキュリティーに影響します。
HTTP クライアントはサーバーに対し、HTTP 要求内の圧縮されたデータを受け入れることを通知できます。Apache DEFLATE フィルタを有効にすると、カタログやマニフェストなどのメタデータの有線送信サイズを著しく削減できます。カタログやマニフェストなどのメタデータは、通常 90% 圧縮されます。
AddOutputFilterByType DEFLATE text/html application/javascript text/css text/plain
パッケージは URL エンコードされたスラッシュを含むことができます。これらのスラッシュがディレクトリ区切り文字として解釈されないようにするには、これらをデコードしないように Apache に指示します。
AllowEncodedSlashes NoDecode
注 - この設定を省略すると、検索機能に著しいマイナスの影響が生じます。
MaxKeepAliveRequests の値を増加することで、クライアントが接続をクローズすることなく多数のパイプライン要求を作成できるようになります。Apache のデフォルトの 100 では少なすぎます。
MaxKeepAliveRequests 10000
プロキシタイムアウトは、バックエンド集積からの応答を Apache が待機する時間を設定します。ほとんどの操作では、30 秒あれば十分です。結果の件数が非常に多くなる検索は、時間がかなり長くなる可能性があります。このような検索に対応するために、タイムアウト値を大きくする場合もあります。
ProxyTimeout 30
フォワードプロキシが無効になっていることを確認します。
ProxyRequests Off
このセクションでは、複数のリポジトリを使用した、負荷分散されていない設定と負荷分散された設定を示します。
この例では、負荷分散されていない集積サーバーの基本構成を示します。この例では http://pkg.example.com/myrepo を internal.example.com:10000 に接続します。
この例で説明していない、必要なその他のプロパティーの設定については、「複数の集積サーバーインスタンスを使用した複数のリポジトリの提供」を参照してください。
集積サーバーは、集積サーバーへのアクセスが可能な URL を指定する pkg/proxy_base 設定を使用して構成する必要があります。pkg/proxy_base を設定するには次のコマンドを使用します。
# svccfg -s pkg/server add repo # svccfg -s pkg/server:repo addpg pkg application # svccfg -s pkg/server:repo "setprop pkg/proxy_base = astring: http://pkg.example.com/myrepo" # svcadm refresh pkg/server:repo # svcadm enable pkg/server:repo
ネットワーク処理を実行するとき、pkg(5) クライアントは集積サーバーに対して 20 個の並列接続を開きます。集積スレッドの数が、任意の時点で予想されるサーバーへの接続と一致するようにします。集積ごとのスレッド数を設定するには次のコマンドを使用します。
# svccfg -s pkg/server:repo "setprop pkg/threads = 200" # svcadm refresh pkg/server:repo # svcadm restart pkg/server:repo
URL の正規化を抑制するには nocanon を使用します。この設定は検索を正しく機能させる上で重要です。また、バックエンド接続の数は、集積サーバーが提供するスレッド数に制限します。次に示す httpd.conf ファイルの一部は、1 つの集積サーバーのプロキシを設定する方法を示しています。
Redirect /myrepo http://pkg.example.com/myrepo/ ProxyPass /myrepo/ http://internal.example.com:10000 nocanon max=200
集積サーバーをプロキシの背後で実行するもっとも重要な理由は、1 つのドメイン名において異なるプレフィックスを使用して複数のリポジトリを簡単に実行することです。「プレフィックスを使用した単純なプロキシ構成」の例は、複数のリポジトリをサポートするように簡単に拡張できます。
次の例では、1 つのドメイン名の 3 種類のプレフィックスが 3 種類のパッケージリポジトリに接続されます。
http://pkg.example.com/repo_one は internal.example.com:10000 に接続されます
http://pkg.example.com/repo_two は internal.example.com:20000 に接続されます
http://pkg.example.com/xyz/repo_three は internal.example.com:30000 に接続されます
pkg(5) 集積サーバーは SMF 管理対象サービスです。したがって、同じホスト上で複数の集積サーバーを実行するには、単純に新しいサービスインスタンスを作成します。
# svccfg -s pkg/server add repo1 # svccfg -s pkg/server:repo1 addpg pkg application # svccfg -s pkg/server:repo1 setprop pkg/property=value # ...
前の例と同様、各集積サーバーは 200 個のスレッドを実行します。
Redirect /repo_one http://pkg.example.com/repo_one/ ProxyPass /repo_one/ http://internal.example.com:10000 nocanon max=200 Redirect /repo_two http://pkg.example.com/repo_two/ ProxyPass /repo_two/ http://internal.example.com:20000 nocanon max=200 Redirect /xyz/repo_three http://pkg.example.com/xyz/repo_three/ ProxyPass /xyz/repo_three/ http://internal.example.com:30000 nocanon max=200
集積サーバーを Apache ロードバランサの背後で実行させることが必要な場合もあります。この例では http://pkg.example.com/myrepo を internal1.example.com:10000 および internal2.example.com:10000 に接続します。
「プレフィックスを使用した単純なプロキシ構成」で示すように、適切な proxy_base 設定を使用して集積サーバーを構成します。
バックエンド接続の数は、ロードバランサ設定において各集積が実行するスレッド数を集積の数で割った数に制限します。それ以外の場合、Apache は 1 つの集積に対して使用可能な数よりも多くの接続を開くことで接続が停止し、パフォーマンスを低下させる可能性があります。max= パラメータを使用して、各集積への並列接続の最大数を指定します。次の例では、それぞれ 200 個のスレッドを実行する 2 つの集積を示します。集積のスレッド数を設定する方法の例については、「プレフィックスを使用した単純なプロキシ構成」を参照してください。
<Proxy balancer://pkg-example-com-myrepo>
# depot on internal1
BalancerMember http://internal1.example.com:10000 retry=5 max=100
# depot on internal2
BalancerMember http://internal2.example.com:10000 retry=5 max=100
</Proxy>
Redirect /myrepo http://pkg.example.com/myrepo/
ProxyPass /myrepo/ balancer://pkg-example-com-myrepo nocanon
次の例は、負荷分散に対応した集積サーバーおよび負荷分散に対応しない集積サーバーの設定をホストするリポジトリサーバーのために、httpd.conf ファイルに追加する必要があるすべてのディレクティブを含んでいます。
次の例では、1 つのドメイン名の 2 種類のプレフィックスが 3 種類のパッケージリポジトリに接続されます。
http://pkg.example.com/repo_one は internal1.example.com:10000 および internal2.example.com:10000 に接続されます
http://pkg.example.com/repo_two は internal1.example.com:20000 に接続されます
AddOutputFilterByType DEFLATE text/html application/javascript text/css text/plain
AllowEncodedSlashes NoDecode
MaxKeepAliveRequests 10000
ProxyTimeout 30
ProxyRequests Off
<Proxy balancer://pkg-example-com-repo_one>
# depot on internal1
BalancerMember http://internal1.example.com:10000 retry=5 max=100
# depot on internal2
BalancerMember http://internal2.example.com:10000 retry=5 max=100
</Proxy>
Redirect /repo_one http://pkg.example.com/repo_one/
ProxyPass /repo_one/ balancer://pkg-example-com-repo_one nocanon
Redirect /repo_two http://pkg.example.com/repo_two/
ProxyPass /repo_two/ http://internal.example.com:20000 nocanon max=200
|