From kondo.hideaki ＠ oss.ntt.co.jp Fri Aug 21 13:03:14 2009 From: kondo.hideaki ＠ oss.ntt.co.jp (Hideaki Kondo) Date: Fri, 21 Aug 2009 13:03:14 +0900 Subject: [Ultramonkey-l7-develop 494] Re: =?iso-2022-jp?b?bDdkaXJlY3RvcmQgGyRCJE4bKEIgcmVxdWVzdCwgcmVj?= =?iso-2022-jp?b?ZWl2ZSAbJEIkRyVBJSclQyUvJDkka0hPME8bKEI=?= In-Reply-To: <20090820.211509.75173119812673755.kt@wheel.jp> References: <4A8D0638.9080509@nttcom.co.jp> <20090820.211509.75173119812673755.kt@wheel.jp> Message-ID: <20090821124729.1B3E.1BAEE5B0@oss.ntt.co.jp> 立石さん、田沼さん近藤です。お疲れさまです。本件ですが、私も以下の考えに賛成です。やはり、元に戻した方が良いと考えます。 > > 確かに直感的にはコンテンツを考えそうなので content に > > 戻してもいいような気がします。 > > 別のオプションで残してヘッダも見れた方がいいですかねー？ > > 私としては receive で $res->content を見るだけとしたいです。立石さんも指摘されてますように、ヘッダ部にどのような文字列が含まれる可能性があるかを意識して receive を設定しておかないと予期せぬ動き（判定）となってしまうためです。事実上、ヘッダ部に含まれる可能性のある文字列をすべて洗い出すことは不可能（どんな文字列でも含まれる可能性があります）ですし、その点をユーザに意識させてreceive を設定してもらうことは困難ですし、望ましくないと考えます。また、この判定範囲の仕様が、既存のUltraMonkey(L4)に含まれる ldirectord と異なってしまいますと、UM-L7と両方使ったり、知っているユーザにとって混乱を招いてしまうと思いますので。。。以上よろしくお願い致します。 On Thu, 20 Aug 2009 21:15:09 +0900 (JST) TATEISHI Katsuyuki wrote: > 立石です。 > > From: Kohei TANUMA > Subject: [Ultramonkey-l7-develop 491] Re: l7directord の request, receive でチェックする範囲 > Date: Thu, 20 Aug 2009 17:15:52 +0900 > > > receive のパターンの範囲ですが、 > > 実は 2.0.0 のときは content になっていてコンテンツだけを > > チェックしていました。 > > その後、2.1.0 のときにヘッダにもマッチした方が > > receive = "200 OK" とかできていいんじゃない？ > > という安易な考えて as_string (ヘッダ込み) に変更しました。 > > なるほど、そういうことだったんですね。 > > > 確かに直感的にはコンテンツを考えそうなので content に > > 戻してもいいような気がします。 > > 別のオプションで残してヘッダも見れた方がいいですかねー？ > > 私としては receive で $res->content を見るだけとしたいです。 > > 単に「ステータスが200 OK ならOKでえーんちゃうん？コンテンツの > 内容とかいちいち考えるのがめんどくさいわ」ということであれば、 > l7directord の現在の実装では HTTP レスポンスは 2xx (成功)が返っ > てこないと receive のチェックまではしませんから、 > receive = ".*" > を設定すればいいわけですし(動作確認してませんが・・・)。 > > どうしてもステータスラインやヘッダを見たい場合、as_string で > メッセージ全体をマッチさせると予期せぬ動きをする場合がありそ > うなので、調べる対象のヘッダ名(またはステータス) と、その値と > の組み合わせを設定できるようにするべきだと思います。 > > -- > TATEISHI Katsuyuki -- Hideaki Kondo From tanuma.kouhei ＠ nttcom.co.jp Fri Aug 21 16:24:05 2009 From: tanuma.kouhei ＠ nttcom.co.jp (Kohei TANUMA) Date: Fri, 21 Aug 2009 16:24:05 +0900 Subject: [Ultramonkey-l7-develop 495] =?iso-2022-jp?b?U1NMUHJveHkgGyRCJE4lOyVDJTclZyVzJS0lYyVDJTcbKEI=?= =?iso-2022-jp?b?GyRCJWVJVDZxOWdCUDF+GyhC?= Message-ID: <4A8E4B95.9060809@nttcom.co.jp> 皆様田沼です。検証中のところ申し訳ないのですが、SSLProxy の session_cache 設定が無視される不具合がありましたので、修正版を ssl-cache-fix に登録しています。大変申し訳ありませんが、今回のリリースに含めていただきたく SSLProxy 部分について、一通り検証していただけますでしょうか。 commit e6b787eca63e317fe227b2c5dd9462d3a4ced286 Author: Kohei TANUMA Date: Fri Aug 21 11:22:51 2009 +0900 Fix to ignore 'session_cache' bug. diff --git a/src/sslproxysession.cpp b/src/sslproxysession.cpp index 85d354f..4bb93e9 100644 --- a/src/sslproxysession.cpp +++ b/src/sslproxysession.cpp @@ -438,11 +438,15 @@ void sslproxy_session::destroy_session(sslproxy_session* session) } } else if (s_r_event || s_w_event) { // Server event remain. - // Set expire time for session cache. - cache_timer.expires_from_now(boost::posix_time::seconds(session_cache_timeout)); - cache_timer.async_wait(boost::bind(&sslproxy_session::cache_expire, + if (session_cache_mode == SSL_SESS_CACHE_OFF) { + server_socket.cancel(); + } else { + // Set expire time for session cache. + cache_timer.expires_from_now(boost::posix_time::seconds(session_cache_timeout)); + cache_timer.async_wait(boost::bind(&sslproxy_session::cache_expire, this, boost::asio::placeholders::error)); + } } } } From tateishi.katsuyuki ＠ oss.ntt.co.jp Fri Aug 21 16:46:08 2009 From: tateishi.katsuyuki ＠ oss.ntt.co.jp (TATEISHI Katsuyuki) Date: Fri, 21 Aug 2009 16:46:08 +0900 (JST) Subject: [Ultramonkey-l7-develop 496] Re: =?iso-2022-jp?b?U1NMUHJveHkgGyRCJE4lOyVDJTclZyVzJS0lYyVDGyhC?= =?iso-2022-jp?b?GyRCJTclZUlUNnE5Z0JQMX4bKEI=?= In-Reply-To: <4A8E4B95.9060809@nttcom.co.jp> References: <4A8E4B95.9060809@nttcom.co.jp> Message-ID: <20090821.164608.575506240494368934.tateishi.katsuyuki@oss.ntt.co.jp> 立石です。 From: Kohei TANUMA Subject: [Ultramonkey-l7-develop 495] SSLProxy のセッションキャッシュ不具合対応 Date: Fri, 21 Aug 2009 16:24:05 +0900 > 大変申し訳ありませんが、今回のリリースに含めていただきたく > SSLProxy 部分について、一通り検証していただけますでしょうか。了解です。今回の変更部分の確認方法をお願いします。また、下記の項目のうち、(1), (2), (5), (6), (8) は変更箇所と関係が薄そうなので省略したいと思います。 ============================================================ >> sslproxy ============================================================ (1) OS をクリーンインストール後，sslproxy をインストールできること・rpm -i でインストール時，rpm コマンドの戻り値が 0 になる (2) 下記のファイルがインストールされていること /etc/l7vs/sslproxy/dh512.pem /etc/l7vs/sslproxy/passwd.txt /etc/l7vs/sslproxy/root.pem /etc/l7vs/sslproxy/server.pem /etc/l7vs/sslproxy/sslproxy.logger_init.cf /etc/l7vs/sslproxy/sslproxy.target.cf /etc/l7vs/sslproxy/sslproxyadm.cf /etc/logrotate.d/sslproxy /usr/sbin/sslproxy /usr/sbin/sslproxyadm /usr/share/doc/sslproxy-1.0.2-0.rc1/README (3) sslproxyadm start で起動できること (事前にsslproxy.target.cf の target_endpoint を適切に書き換えること) (4) 待ち受けアドレス・ポートにアクセスし、HTTPクライアント、サーバともにエラーが発生しないこと (5) 以下の設定を追加し、リクエストに X-Forwarded-For を追加して、リアルサーバ側でクライアント IP を確認できること。 http_request_header = "add:X-Forwarded-For:%{CLIENT_ADDR}" リアルサーバ側は環境変数を出力するCGIにアクセスする or アクセスログにX-Forwarded-For を出力するようhttpd.conf を設定するなどして確認してください。 (6) 以下の設定を追加して HTML のコンテンツにアクセスし、レスポンスの Content-type が text/plain になること。 http_response_header = "replace:Content-Type:html:plain" Live HTTP Headers や ieHTTPheaders などのHTTPリクエストヘッダを確認できるツールをブラウザに導入して確認してください。 (7) sslproxyadm stop で停止できること (8) アンインストールできること・rpm -e でアンインストール時，コマンドの戻り値が 0 になる -- TATEISHI Katsuyuki From takebayashi.shinya ＠ oss.ntt.co.jp Fri Aug 21 17:15:43 2009 From: takebayashi.shinya ＠ oss.ntt.co.jp (Shinya TAKEBAYASHI) Date: Fri, 21 Aug 2009 17:15:43 +0900 Subject: [Ultramonkey-l7-develop 497] Re: =?iso-2022-jp?b?TVEbJEIkSBsoQlJQUxskQiRYJE4lZiE8JTYhPDZ1GyhC?= =?iso-2022-jp?b?GyRCNFYkKyRpJE4lIiVXJW0hPCVBJEskRCQkJEYbKEI=?= In-Reply-To: <4A8D3F9F.8000101@sdy.co.jp> References: <4A8D3F9F.8000101@sdy.co.jp> Message-ID: 竹林です． > Montrealで行われたLinuxSimposiumでフェルナンド様と話をしていたMonkey側か > らkernel側へのリクエスト用件をまとめました。ありがとうございます． > まず、MQやRPSに最大限対応すべくMultiThreadの設計をすると > http://sourceforge.jp/projects/ultramonkey-l7/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%83%A2%E3%83%87%E3%83%AB > このリンク先の説明になります。 > 方式的には「CPUに結びついたThreadPoolを持つ」のが特色でしょうか。論理 CPU の数だけスレッドプールを作って，各々のスレッドプールに各ソケットを処理するスレッドをプーリングする，という思想で良いでしょうか． sched_setaffinity に tid と mask を渡して，擬似的にスレッドプールを作るような・・・． > そして、タイトルにあるようにこの方式を実現するためにはkernelから情報を取 > 得出来なければなりません。 > その案を示しました。 > http://sourceforge.jp/projects/ultramonkey-l7/wiki/KernelRequestL7vsd wiki にまとめて頂いている情報を整理すると・・・・UM-L7 起動時に必要な情報 - MultiQueuing の使用可否（使うか否かではなく，使えるか否か） → スレッドプールを分散させるか否かの判断をするために必要． - Queue の総数 → どれだけスレッドプールを作れるかを判断するために必要． NIC の queue の数が CPU 数を下回る可能性があるため． e.g.: i82575 だと RX も TX も 4 本しかないので，8cores 以上だと一杯一杯に使えない． - CPU 数 → いくつスレッドプールを作るかを決めるために必要． - ハッシュ関数のインタフェイス → リアルサーバに一番近いどんな情報が必要かも含む．・コネクションの処理にあたって必要な情報 - FD に紐付いた CPU → FD を握っている CPU が持つスレッドプールを特定するために必要． - Queue 割り付けのハッシュ → リアルサーバ通信用スレッドを起こすためにスレッドプールを特定するために必要．といったところでしょうか．方式の面では，先日話したように，起動時にのみ必要な情報は sysfs などで，コネクション処理で必要な情報については ioctl などで取ってくるようにした方が良いかもしれません．＃ sockaddr_storage を内包する構造を新しく定義するとか必要？必要な情報についてもう少し精査しましょう． ----------------------------------------------------------- Shinya TAKEBAYASHI E-mail: takebayashi.shinya ＠ oss.ntt.co.jp GPG ID: 395EFCE8 GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 ----------------------------------------------------------- From tanuma.kouhei ＠ nttcom.co.jp Fri Aug 21 17:19:55 2009 From: tanuma.kouhei ＠ nttcom.co.jp (Kohei TANUMA) Date: Fri, 21 Aug 2009 17:19:55 +0900 Subject: [Ultramonkey-l7-develop 498] Re: =?iso-2022-jp?b?U1NMUHJveHkgGyRCJE4lOyVDJTclZyVzJS0lYyVDGyhC?= =?iso-2022-jp?b?GyRCJTclZUlUNnE5Z0JQMX4bKEI=?= In-Reply-To: <20090821.164608.575506240494368934.tateishi.katsuyuki@oss.ntt.co.jp> References: <4A8E4B95.9060809@nttcom.co.jp> <20090821.164608.575506240494368934.tateishi.katsuyuki@oss.ntt.co.jp> Message-ID: <4A8E58AB.5010304@nttcom.co.jp> 立石さま田沼です。 session_cache = "off", session_cache = "on" それぞれに対して以下のコマンドでご確認をお願い致します。 # openssl s_client -host IP-ADDR -port PORT -reconnect 2>&1 | \ egrep -i "(Session-ID:|^reuse|^new|connect)" s_client の reconnect で同じ Session-ID で 5 回接続します。 (例) session_cache = "on" の場合 # openssl s_client -host 127.0.0.1 -port 443 -reconnect 2>&1 | \ egrep -i "(Session-ID:|^reuse|^new|connect)" CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: D81A6181139BA7063C31F91B0C5D25... drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: D81A6181139BA7063C31F91B0C5D25... drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: D81A6181139BA7063C31F91B0C5D25... drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: D81A6181139BA7063C31F91B0C5D25... drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: D81A6181139BA7063C31F91B0C5D25... drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: D81A6181139BA7063C31F91B0C5D25... 最初が New で残り 5 回が Reused になっていること、 Session-ID が同じことを確認してください。 (例) session_cache = "off" の場合 # openssl s_client -host 127.0.0.1 -port 443 -reconnect 2>&1 | \ egrep -i "(Session-ID:|^reuse|^new|connect)" CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: 全ての接続が New で、Session-ID が表示されないことを確認してください。宜しくお願い致します。 From tateishi.katsuyuki ＠ oss.ntt.co.jp Fri Aug 21 17:20:38 2009 From: tateishi.katsuyuki ＠ oss.ntt.co.jp (TATEISHI Katsuyuki) Date: Fri, 21 Aug 2009 17:20:38 +0900 (JST) Subject: [Ultramonkey-l7-develop 499] Re: =?iso-2022-jp?b?U1NMUHJveHkgGyRCJE4lOyVDJTclZyVzJS0lYyVDGyhC?= =?iso-2022-jp?b?GyRCJTclZUlUNnE5Z0JQMX4bKEI=?= In-Reply-To: <20090821.164608.575506240494368934.tateishi.katsuyuki@oss.ntt.co.jp> References: <4A8E4B95.9060809@nttcom.co.jp> <20090821.164608.575506240494368934.tateishi.katsuyuki@oss.ntt.co.jp> Message-ID: <20090821.172038.57809164209507948.tateishi.katsuyuki@oss.ntt.co.jp> 立石です。 http://ultramonkey-l7.sourceforge.jp/_tmp/sslproxy-1.0.2-0/ に RC3 版を追加しました。 From: TATEISHI Katsuyuki Subject: [Ultramonkey-l7-develop 496] Re: SSLProxy のセッションキャッシュ不具合対応 Date: Fri, 21 Aug 2009 16:46:08 +0900 (JST) > From: Kohei TANUMA > Subject: [Ultramonkey-l7-develop 495] SSLProxy のセッションキャッシュ不具合対応 > Date: Fri, 21 Aug 2009 16:24:05 +0900 > >> 大変申し訳ありませんが、今回のリリースに含めていただきたく >> SSLProxy 部分について、一通り検証していただけますでしょうか。 > > 了解です。 > 今回の変更部分の確認方法をお願いします。通常動作を確認したあと、sslproxy.target.cf の session_cache を session_cache = "off" に変更し、sslproxy を再起動、クライアントからの連続したアクセス時にSSLセッションIDが再利用されない(クライアントからオファーしたものとは違うセッションIDがサーバから割り当てられる)のを確認するでいいですか？ # wget じゃなくて普通のブラウザ & パケットキャプチャが必要かも -- TATEISHI Katsuyuki From tateishi.katsuyuki ＠ oss.ntt.co.jp Fri Aug 21 17:22:22 2009 From: tateishi.katsuyuki ＠ oss.ntt.co.jp (TATEISHI Katsuyuki) Date: Fri, 21 Aug 2009 17:22:22 +0900 (JST) Subject: [Ultramonkey-l7-develop 500] Re: =?iso-2022-jp?b?U1NMUHJveHkgGyRCJE4lOyVDJTclZyVzJS0lYyVDGyhC?= =?iso-2022-jp?b?GyRCJTclZUlUNnE5Z0JQMX4bKEI=?= In-Reply-To: <4A8E58AB.5010304@nttcom.co.jp> References: <4A8E4B95.9060809@nttcom.co.jp> <20090821.164608.575506240494368934.tateishi.katsuyuki@oss.ntt.co.jp> <4A8E58AB.5010304@nttcom.co.jp> Message-ID: <20090821.172222.145758950124908284.tateishi.katsuyuki@oss.ntt.co.jp> 立石です。入れ違いになってしまいした。 From: Kohei TANUMA Subject: Re: [Ultramonkey-l7-develop 495] SSLProxy のセッションキャッシュ不具合対応 Date: Fri, 21 Aug 2009 17:19:55 +0900 > session_cache = "off", session_cache = "on" それぞれに対して > 以下のコマンドでご確認をお願い致します。 > > # openssl s_client -host IP-ADDR -port PORT -reconnect 2>&1 | \ > egrep -i "(Session-ID:|^reuse|^new|connect)" > > s_client の reconnect で同じ Session-ID で 5 回接続します。そんな便利な方法があったんですね。了解しました。 -- TATEISHI Katsuyuki From fernando ＠ oss.ntt.co.jp Fri Aug 21 17:50:48 2009 From: fernando ＠ oss.ntt.co.jp (=?UTF-8?B?RmVybmFuZG8gTHVpcyBWw6F6cXVleiBDYW8=?=) Date: Fri, 21 Aug 2009 17:50:48 +0900 Subject: [Ultramonkey-l7-develop 501] Re: =?utf-8?b?TVHjgahSUFPjgbjjga7jg6bjg7zjgrbjg7znqbrplpPjgYs=?= =?utf-8?b?44KJ44Gu44Ki44OX44Ot44O844OB44Gr44Gk44GE44Gm?= In-Reply-To: <4A8D3F9F.8000101@sdy.co.jp> References: <4A8D3F9F.8000101@sdy.co.jp> Message-ID: <4A8E5FE8.70805@oss.ntt.co.jp> 中居様いつもお世話になっております。フェルナンドです。メールをありがとうございました。今ちょっとバタバタしていますが、今週末下記の資料をちゃんと拝見してフィードバックさせて戴こうと思っております。以上、宜しくお願い致します。中居憲久さんは書きました: > TO:フェルナンド様、竹林様、中野様、岡田様 > CC:Monkey-develop > > 中居です。 > お疲れ様です。 > > MultiQueueそしてRPSやFlowDirectorなどlinuxを取り巻くネットワーク環境は > 今非常に速い速度で進化しております。 > Montrealで行われたLinuxSimposiumでフェルナンド様と話をしていたMonkey側か > らkernel側へのリクエスト用件をまとめました。 > > まず、MQやRPSに最大限対応すべくMultiThreadの設計をすると > http://sourceforge.jp/projects/ultramonkey-l7/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%83%A2%E3%83%87%E3%83%AB > このリンク先の説明になります。 > 方式的には「CPUに結びついたThreadPoolを持つ」のが特色でしょうか。 > > そして、タイトルにあるようにこの方式を実現するためにはkernelから情報を取 > 得出来なければなりません。 > その案を示しました。 > http://sourceforge.jp/projects/ultramonkey-l7/wiki/KernelRequestL7vsd > > 上記は中居が意識している部分でまとめました。 > 足りない部分、もしくはもっとよい方法が存在する部分、 > 間違っている部分(RPSの送信側については調査が不十分ですし、 > MultiQueue+RPSも出来ますが動きをまだ考え切れていません)等がまだ残ってい > ると考えられます。 > > 一度目を通していただき、些細なことでかまいませんので > コメントをいただけますと幸いかと思います。 > > どうぞよろしくお願いします。 From sugiura.jun ＠ oss.ntt.co.jp Fri Aug 21 18:33:27 2009 From: sugiura.jun ＠ oss.ntt.co.jp (Jun Sugiura) Date: Fri, 21 Aug 2009 18:33:27 +0900 Subject: [Ultramonkey-l7-develop 502] =?iso-2022-jp?b?GyRCJWolaiE8JTlBMDghPlo3azJMSnM5cCFKGyhCeDg2XzY0?= =?iso-2022-jp?b?GyRCIUsbKEI=?= Message-ID: <20090821183024.7416.9A97E586@oss.ntt.co.jp> 杉浦です。 ultramonkey-l7-2.1.3-0 および sslproxy-1.0.2-0 の x86_64版のリリース前検証を実施し、特に問題のないことを確認しました。　※実施項目内容は下記を参照ください。　※sslproxy は全て sslproxy-1.0.2-0.rc3.x86_64.rpm 　　にて実施しました。 -------------------------------------------------- > 検証項目は以下の通りです。 > ============================================================ > >> ultramonkey-l7 > ============================================================ > > (1) OS をクリーンインストール後，UM-L7 をインストールできること > ・rpm -i でインストール時，rpm コマンドの戻り値が 0 になる [root ＠ shared-rhel53-x8664 ultramonkey-l7-2.1.3-0]# rpm -i ultramonkey-l7-2.1.3-0.rc1.x86_64.rpm [root ＠ shared-rhel53-x8664 ultramonkey-l7-2.1.3-0]# echo $? 0 [root ＠ shared-rhel53-x8664 ultramonkey-l7-2.1.3-0]# rpm -qa ultramonkey-l7 ultramonkey-l7-2.1.3-0.rc1 > (2) 2.1.2-2でインストールされていた下記のファイルがインストー > ルされていること > > /etc/ha.d/conf/l7directord.cf.sample [root ＠ shared-rhel53-x8664 ~]# ls -l /etc/ha.d/conf/ | grep l7 -rw-r--r-- 1 root root 1178 8月 17 18:32 l7directord.cf.sample > /etc/init.d/l7directord > /etc/init.d/l7vsd [root ＠ shared-rhel53-x8664 ~]# ls -l /etc/init.d/ | grep l7 -rwxr-xr-x 1 root root 1710 8月 17 18:32 l7directord -rwxr-xr-x 1 root root 1930 8月 17 18:32 l7vsd > /etc/l7vs/l7vs.cf [root ＠ shared-rhel53-x8664 ~]# ls -l /etc/l7vs/ | grep l7 -rw-r--r-- 1 root root 4445 8月 17 18:32 l7vs.cf > /usr/doc/ultramonkey-l7-2.1.2 > /usr/doc/ultramonkey-l7-2.1.2/README [root ＠ shared-rhel53-x8664 ~]# ls -l /usr/share/doc/ | grep l7 drwxr-xr-x 3 root root 4096 8月 21 07:53 ultramonkey-l7-2.1.3-0.rc1 [root ＠ shared-rhel53-x8664 ~]# ls -l /usr/share/doc/ultramonkey-l7-2.1.3-0.rc1/README -rw-r--r-- 1 root root 955 8月 17 18:32 /usr/share/doc/ultramonkey-l7-2.1.3-0.rc1/README > /usr/lib64/l7vs/protomod_ip.so > /usr/lib64/l7vs/protomod_pfilter.so > /usr/lib64/l7vs/protomod_sessionless.so > /usr/lib64/l7vs/protomod_sslid.so > /usr/lib64/l7vs/protomod_url.so > /usr/lib64/l7vs/sched_lc.so > /usr/lib64/l7vs/sched_rr.so > /usr/lib64/l7vs/sched_wrr.so [root ＠ shared-rhel53-x8664 ~]# ls -l /usr/lib64/l7vs/ | grep so -rwxr-xr-x 1 root root 35872 8月 17 18:32 protomod_ip.so -rwxr-xr-x 1 root root 40120 8月 17 18:32 protomod_pfilter.so -rwxr-xr-x 1 root root 32904 8月 17 18:32 protomod_sessionless.so -rwxr-xr-x 1 root root 62096 8月 17 18:32 protomod_sslid.so -rwxr-xr-x 1 root root 44880 8月 17 18:32 protomod_url.so -rwxr-xr-x 1 root root 9800 8月 17 18:32 sched_lc.so -rwxr-xr-x 1 root root 11048 8月 17 18:32 sched_rr.so -rwxr-xr-x 1 root root 15656 8月 17 18:32 sched_wrr.so > /usr/sbin/l7directord > /usr/sbin/l7vsadm > /usr/sbin/l7vsd [root ＠ shared-rhel53-x8664 ~]# ls -l /usr/sbin/ | grep l7 -rwxr-xr-x 1 root root 152925 8月 17 18:32 l7directord -rwxr-xr-x 1 root root 334032 8月 17 18:32 l7vsadm -rwxr-xr-x 1 root root 562256 8月 17 18:32 l7vsd > /usr/share/man/man8/l7directord.8.gz > /usr/share/man/man8/l7vsadm.8.gz > /usr/share/man/man8/l7vsd.8.gz [root ＠ shared-rhel53-x8664 ~]# ls -l /usr/share/man/man8/ | grep l7 -rw-r--r-- 1 root root 7723 8月 17 18:32 l7directord.8.gz -rw-r--r-- 1 root root 1662 8月 17 18:32 l7vsadm.8.gz -rw-r--r-- 1 root root 406 8月 17 18:32 l7vsd.8.gz > (3) /usr/share/doc/ultramonkey-l7-2.1.3-0.rc1 配下に以下のファ > イルがインストールされていること > > README [root ＠ shared-rhel53-x8664 ~]# ls -l /usr/share/doc/ultramonkey-l7-2.1.3-0.rc1/README -rw-r--r-- 1 root root 955 8月 17 18:32 /usr/share/doc/ultramonkey-l7-2.1.3-0.rc1/README > heartbeat-ra/L7directord > heartbeat-ra/L7vsd > heartbeat-ra/README > heartbeat-ra/SSLProxy > heartbeat-ra/VIPcheck > heartbeat-ra/authkeys > heartbeat-ra/cib.xml-sample > heartbeat-ra/cib.xml-sample.sslproxy > heartbeat-ra/ha.cf > heartbeat-ra/logd.cf [root ＠ shared-rhel53-x8664 ~]# ls -l /usr/share/doc/ultramonkey-l7-2.1.3-0.rc1/heartbeat-ra/ 合計 60 -rw-r--r-- 1 root root 6123 8月 17 18:32 L7directord -rw-r--r-- 1 root root 5935 8月 17 18:32 L7vsd -rw-r--r-- 1 root root 686 8月 17 18:32 README -rw-r--r-- 1 root root 5708 8月 17 18:32 SSLProxy -rw-r--r-- 1 root root 3879 8月 17 18:32 VIPcheck -rw-r--r-- 1 root root 27 8月 17 18:32 authkeys -rw-r--r-- 1 root root 5564 8月 17 18:32 cib.xml-sample -rw-r--r-- 1 root root 6920 8月 17 18:32 cib.xml-sample.sslproxy -rw-r--r-- 1 root root 399 8月 17 18:32 ha.cf -rw-r--r-- 1 root root 69 8月 17 18:32 logd.cf > (4) インストール直後、chkconfig l7vsd --list の出力が > l7vsd 0:off 1:off 2:off 3:off 4:off 5:off 6:off > となっていること(全off) [root ＠ shared-rhel53-x8664 ~]# chkconfig l7vsd --list l7vsd 0:off 1:off 2:off 3:off 4:off 5:off 6:off > (5) chkconfig l7vsd on 実行後、chkconfig l7vsd --list の出力が > l7vsd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > となっていること(runlevel 2,3,4,5 で on, 残りoff) [root ＠ shared-rhel53-x8664 ~]# chkconfig l7vsd on [root ＠ shared-rhel53-x8664 ~]# chkconfig l7vsd --list l7vsd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > (6) インストール直後、chkconfig l7directord --list の出力が > l7directord 0:off 1:off 2:off 3:off 4:off 5:off 6:off > となっていること(全off) [root ＠ shared-rhel53-x8664 ~]# chkconfig l7directord --list l7directord 0:off 1:off 2:off 3:off 4:off 5:off 6:off > (7) chkconfig l7directord on 実行後、chkconfig l7directord --list の出力が > l7directord 0:off 1:off 2:on 3:on 4:on 5:on 6:off > となっていること(runlevel 2,3,4,5 で on, 残りoff) [root ＠ shared-rhel53-x8664 ~]# chkconfig l7directord on [root ＠ shared-rhel53-x8664 ~]# chkconfig l7directord --list l7directord 0:off 1:off 2:on 3:on 4:on 5:on 6:off > (8) UltraMonkey-L7 が起動すること > ・/etc/init.d/l7vsd start で l7vsd が起動すること > ・l7vsadm コマンドを実行し，ステータスが確認できること [root ＠ shared-rhel53-x8664 ~]# /etc/init.d/l7vsd start Starting l7vsd: done. [root ＠ shared-rhel53-x8664 ~]# l7vsadm Layer-7 Virtual Server version 2.1.3-0.rc1 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 192.168.0.33:http sessionless rr -> 192.168.10.11:http Masq 1 0 0 > (9) sslid モジュールが0.0.0.0での待ち受けで設定できること > ・l7vsadm -A -t 0.0.0.0:XXX -m sslid 実行時， > コマンドの戻り値が 0 になる [root ＠ shared-rhel53-x8664 ~]# l7vsadm -A -t 0.0.0.0:440 -m sslid [root ＠ shared-rhel53-x8664 ~]# echo $? 0 > (10) リアルサーバの追加ができること > ・l7vsadm -a -t 0.0.0.0:XXX -m sslid \ > -r ZZZ.ZZZ.ZZZ.ZZZ:ZZZ > > 実行時，コマンドの戻り値が 0 になる [root ＠ shared-rhel53-x8664 ~]# l7vsadm -a -t 0.0.0.0:440 -m sslid -r 192.160.10.1:444 [root ＠ shared-rhel53-x8664 ~]# echo $? 0 [root ＠ shared-rhel53-x8664 ~]# l7vsadm -l -n Layer-7 Virtual Server version 2.1.3-0.rc1 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 192.168.0.33:80 sessionless rr -> 192.168.10.11:80 Masq 1 0 0 TCP 0.0.0.0:440 sslid rr -> 192.160.10.1:444 Masq 1 0 0 > (11) l7directord.cf に (9)(10) の内容を設定し，動作すること [root ＠ shared-rhel53-x8664 conf]# tail -3 /etc/ha.d/conf/l7directord.cf virtual = 0.0.0.0:440 real = 192.168.10.1:444 masq 1 module = sslid [root ＠ shared-rhel53-x8664 conf]# l7vsadm -l -n Layer-7 Virtual Server version 2.1.3-0.rc1 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 192.168.0.33:80 sessionless rr -> 192.168.10.11:80 Masq 1 0 0 TCP 0.0.0.0:440 sslid rr -> 192.168.10.1:444 Masq 1 0 0 > (12) バーチャルサーバに 1000 回アクセスし、HTTPクライアント、 > サーバともにエラーが発生しないこと。 [root ＠ umclient01 work]# for i in `seq 1 1000` > do > wget http://192.168.0.33:8090/index.html > done --17:04:21-- http://192.168.0.33/index.html => `index.html' 192.168.0.33:80 に接続しています... 接続しました。 HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 69 [text/html] 100%[========================================================>] 69 --.--K/s 17:04:21 (9.40 MB/s) - `index.html' を保存しました [69/69] 　・　・　・ --17:04:29-- http://192.168.0.33/index.html => `index.html.999' 192.168.0.33:80 に接続しています... 接続しました。 HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 69 [text/html] 100%[========================================================>] 69 --.--K/s 17:04:29 (9.40 MB/s) - `index.html.999' を保存しました [69/69] [root ＠ umclient01 work]# ls | wc -w 1000 > (13) 上記(12)実行後 l7vsadm で InactConn が 1000 になっている > こと。 [root ＠ shared-rhel53-x8664 conf]# l7vsadm -l -n Layer-7 Virtual Server version 2.1.3-0.rc1 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 192.168.0.33:80 sessionless rr -> 192.168.10.11:80 Masq 1 0 1000 TCP 0.0.0.0:440 sslid rr -> 192.168.10.1:444 Masq 1 0 0 > (14) l7directord.cf に以下の内容(--forwarded-for)を設定し、 > keep-alive で 1 コネクション中に複数リクエストを送って、 > 全てに X-Forwarded-For がついていることを確認する。 > > virtual=0.0.0.0:XXX > real=ZZZ.ZZZ.ZZZ.ZZZ:ZZZ > module=sessionless --forwarded-for --- [root ＠ shared-rhel53-x8664 conf]# l7vsadm Layer-7 Virtual Server version 2.1.3-0.rc1 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 0.0.0.0:http sessionless rr -> 192.168.10.11:http Masq 1 0 0 [root ＠ shared-rhel53-x8664 conf]# --- [root ＠ local_web01 ~]# cat /etc/httpd/conf/httpd.conf | grep X-Forwarded-For LogFormat "%{X-Forwarded-For}i" xf [root ＠ local_web01 ~]# cat /etc/httpd/conf/httpd.conf | grep xf_log CustomLog logs/xf_log xf [root ＠ local_web01 ~]# tail -f /var/log/httpd/xf_log - 192.168.10.12 192.168.10.12 192.168.10.12 - [root ＠ local_web01 ~]# --- [root ＠ local_web02 tmp]# wget http://shared-rhel53-x8664/index.html http://shared-rhel53-x8664/index.html http://shared-rhel53-x8664/index.html --02:17:31-- http://shared-rhel53-x8664/index.html shared-rhel53-x8664 をDNSに問いあわせています... 192.168.10.97 shared-rhel53-x8664|192.168.10.97|:80 に接続しています... 接続しました。 HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 69 [text/html] Saving to: `index.html' 100%[===========================================================>] 69 --.-K/s in 0s 02:17:31 (6.58 MB/s) - `index.html' を保存しました [69/69] --02:17:31-- http://shared-rhel53-x8664/index.html shared-rhel53-x8664:80 への接続を再利用します。 HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 69 [text/html] Saving to: `index.html.1' 100%[===========================================================>] 69 --.-K/s in 0s 02:17:31 (135 KB/s) - `index.html.1' を保存しました [69/69] --02:17:31-- http://shared-rhel53-x8664/index.html shared-rhel53-x8664:80 への接続を再利用します。 HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 69 [text/html] Saving to: `index.html.2' 100%[===========================================================>] 69 --.-K/s in 0s 02:17:31 (8.23 MB/s) - `index.html.2' を保存しました [69/69] FINISHED --02:17:31-- Downloaded: 3 files, 207 in 0s (11.0 MB/s) [root ＠ local_web02 tmp]# --- [root ＠ shared-rhel53-x8664 conf]# l7vsadm Layer-7 Virtual Server version 2.1.3-0.rc1 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 0.0.0.0:http sessionless rr -> 192.168.10.11:http Masq 1 0 1 [root ＠ shared-rhel53-x8664 conf]# --- > (15) IP モジュールのタイムアウト確認 > > l7directord.cf に > > virtual=0.0.0.0:80 > real=xxx.xxx.xxx.xxx:80 > real=yyy.yyy.yyy.yyy:80 > module=ip --timeout 5 > > を設定して起動し、l7vsadm -V -n でリアルサーバが 2 つ、 > --timeout 5 が設定されていることを確認する。 > > 適当なクライアントから 5 秒間隔以内で連続アクセスして > 同一のサーバに接続されることを確認する。 > keep-alive オンだとよくわからないので > keep-alive オフで確認してください。 > l7vsadm で接続数が偏って増加しているのを確認するのもありです。 > > 次に 5 秒以上間隔をあけてからアクセスすると、もう片方の > サーバに接続されることを確認してください。 [root ＠ shared-rhel53-x8664 ~]# l7vsadm -V -n 　・　・　・ Prot LocalAddress:Port ProtoMod Scheduler Reschedule Protomod_opt_string SorryAddress:Port Sorry_cc Sorry_flag QoS-up Throughput-up QoS-down Throughput-down -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 0.0.0.0:80 ip rr 0 --timeout 5 192.168.0.53:8080 1000 0 100000000 0 100000000 0 -> 192.168.10.11:80 Masq 1 0 0 -> 192.168.10.12:80 Masq 1 0 0 [root ＠ shared-rhel53-x8664 ~]# date;l7vsadm 2009年 8月 21日金曜日 08:33:34 JST Layer-7 Virtual Server version 2.1.3-0.rc1 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 0.0.0.0:http ip rr -> 192.168.10.11:http Masq 1 0 5 -> 192.168.10.12:http Masq 1 0 0 [root ＠ shared-rhel53-x8664 ~]# date;l7vsadm 2009年 8月 21日金曜日 08:33:39 JST Layer-7 Virtual Server version 2.1.3-0.rc1 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 0.0.0.0:http ip rr -> 192.168.10.11:http Masq 1 0 5 -> 192.168.10.12:http Masq 1 0 1 > (16) sorryserver の設定解除確認 > > l7directord.cf に > > autoreload=yes > virtual=0.0.0.0:8000 > real=10.10.10.10:80 > sorryserver=127.0.0.1:80 > > だけを設定して /etc/init.d/l7directord start で起動。 > l7vsadm -V -n で sorryserver 設定 (127.0.0.1:80) を確認し、 > l7directord.cf の sorryserver 行をコメントアウトして > しばらく待って l7vsadm -V で sorryserver 設定が none に > なっていることを確認。 [root ＠ shared-rhel53-x8664 conf]# cat /etc/ha.d/conf/l7directord.cf autoreload = yes virtual = 0.0.0.0:8000 real = 10.10.10.10:80 masq 1 sorryserver = 127.0.0.1:80 [root ＠ shared-rhel53-x8664 ~]# l7vsadm -V -n 　・　・　・ Prot LocalAddress:Port ProtoMod Scheduler Reschedule Protomod_opt_string SorryAddress:Port Sorry_cc Sorry_flag QoS-up Throughput-up QoS-down Throughput-down -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 0.0.0.0:8000 sessionless rr 1 127.0.0.1:80 0 0 0 0 0 0 -> 10.10.10.10:80 Masq 1 0 0 [root ＠ shared-rhel53-x8664 conf]# cat /etc/ha.d/conf/l7directord.cf autoreload = yes virtual = 0.0.0.0:8000 real = 10.10.10.10:80 masq 1 # sorryserver = 127.0.0.1:80 [root ＠ shared-rhel53-x8664 conf]# l7vsadm -V -n 　・　・　・ Prot LocalAddress:Port ProtoMod Scheduler Reschedule Protomod_opt_string SorryAddress:Port Sorry_cc Sorry_flag QoS-up Throughput-up QoS-down Throughput-down -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 0.0.0.0:8000 sessionless rr 1 none 0 0 0 0 0 0 -> 10.10.10.10:80 Masq 1 0 0 > (17) customcheck のゾンビ対応 > /tmp/ping.sh に以下を記述し実行権付与 > > #!/bin/sh > ping -w 2 1.1.1.1 > > l7directord.cf に > > virtual=127.0.0.1:8000 > real=127.0.0.1:80 > checkinterval=1 > negotiatetimeout=1 > checktype=custom > customcheck=/tmp/ping.sh > > を設定して起動。 > l7vsadm で仮想サービス (127.0.0.1:8000) が存在するのを確認し、 > 定期的に ps -ef | grep ping を実行。 > > [ping.sh] > > が出力されていなければ OK です。 [root ＠ shared-rhel53-x8664 conf]# ls -l /tmp/ping.sh -rwxrwxrwx 1 root root 28 8月 21 08:42 /tmp/ping.sh [root ＠ shared-rhel53-x8664 conf]# cat /tmp/ping.sh #!/bin/sh ping -w 2 1.1.1.1 [root ＠ shared-rhel53-x8664 conf]# cat /etc/ha.d/conf/l7directord.cf checkinterval = 1 negotiatetimeout = 1 virtual = 127.0.0.1:8000 real = 127.0.0.1:80 checktype = custom customcheck = /tmp/ping.sh [root ＠ shared-rhel53-x8664 conf]# [root ＠ shared-rhel53-x8664 conf]# l7vsadm -l -n Layer-7 Virtual Server version 2.1.3-0.rc1 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 127.0.0.1:8000 sessionless rr -> 127.0.0.1:80 Masq 0 0 0 [root ＠ shared-rhel53-x8664 conf]# ps -ef | grep ping root 3242 1 0 07:04 ? 00:00:00 /usr/libexec/mapping-daemon root 13112 3301 0 08:50 pts/1 00:00:00 grep ping > (18) l7directord l7vsadm l7vsd の man が文字化けしないこと > ・man l7directord > ・man l7vsadm > ・l7vsd ※確認のみ。ＯＫ。 > (19) アンインストールできること > ・rpm -e でアンインストール時，コマンドの戻り値が 0 になる [root ＠ shared-rhel53-x8664 ~]# rpm -e ultramonkey-l7 [root ＠ shared-rhel53-x8664 ~]# echo $? 0 [root ＠ shared-rhel53-x8664 ~]# rpm -qa ultramonkey-l7 [root ＠ shared-rhel53-x8664 ~]# > ============================================================ > >> sslproxy > ============================================================ > > (1) OS をクリーンインストール後，sslproxy をインストールできること > ・rpm -i でインストール時，rpm コマンドの戻り値が 0 になる [root ＠ shared-rhel53-x8664 PKG]# rpm -i sslproxy-1.0.2-0.rc3.x86_64.rpm [root ＠ shared-rhel53-x8664 PKG]# echo $? 0 [root ＠ shared-rhel53-x8664 PKG]# rpm -qa sslproxy sslproxy-1.0.2-0.rc3 > (2) 下記のファイルがインストールされていること > > /etc/l7vs/sslproxy/dh512.pem > /etc/l7vs/sslproxy/passwd.txt > /etc/l7vs/sslproxy/root.pem > /etc/l7vs/sslproxy/server.pem > /etc/l7vs/sslproxy/sslproxy.logger_init.cf > /etc/l7vs/sslproxy/sslproxy.target.cf > /etc/l7vs/sslproxy/sslproxyadm.cf [root ＠ shared-rhel53-x8664 PKG]# ls -l /etc/l7vs/sslproxy/ 合計 32 -rw-r--r-- 1 root root 466 8月 21 2009 dh512.pem -rw-r--r-- 1 root root 5 8月 21 2009 passwd.txt -rw-r--r-- 1 root root 1680 8月 21 2009 root.pem -rw-r--r-- 1 root root 2445 8月 21 2009 server.pem -rw-r--r-- 1 root root 989 8月 21 2009 sslproxy.logger_init.cf -rw-r--r-- 1 root root 5160 8月 21 2009 sslproxy.target.cf -rw-r--r-- 1 root root 399 8月 21 2009 sslproxyadm.cf > /etc/logrotate.d/sslproxy [root ＠ shared-rhel53-x8664 PKG]# ls -l /etc/logrotate.d/sslproxy* -rw-r--r-- 1 root root 224 8月 21 2009 /etc/logrotate.d/sslproxy > /usr/sbin/sslproxy > /usr/sbin/sslproxyadm [root ＠ shared-rhel53-x8664 PKG]# ls -l /usr/sbin/sslproxy* -rwxr-xr-x 1 root root 807680 8月 21 2009 /usr/sbin/sslproxy -rwxr-xr-x 1 root root 65689 8月 21 2009 /usr/sbin/sslproxyadm > /usr/share/doc/sslproxy-1.0.2-0.rc1/README [root ＠ shared-rhel53-x8664 PKG]# ls -l /usr/share/doc/sslproxy-1.0.2-0.rc3/README -rw-r--r-- 1 root root 956 8月 21 2009 /usr/share/doc/sslproxy-1.0.2-0.rc3/README > (3) sslproxyadm start で起動できること > (事前にsslproxy.target.cf の target_endpoint を適切に書 > き換えること) [root ＠ shared-rhel53-x8664 ~]# sslproxyadm start [root ＠ shared-rhel53-x8664 ~]# sslproxyadm status ----- Print SSLproxyadm status start ----- [ Common Data ] Common config file : /etc/l7vs/sslproxy/sslproxyadm.cf Output log file : /var/log/l7vs/sslproxy/sslproxyadm.log Output log level : warn Log rotate config file : /etc/logrotate.d/sslproxy Log rotate status file : /var/lib/logrotate.status [ Target Data ] TargetID : target_1 Config file : /etc/l7vs/sslproxy/sslproxy.target.cf Process status : Normal. Execute status : Starting. PID = 13550 [ Unknown SSLproxy process ] ----- Print SSLproxyadm status end ----- > (4) 待ち受けアドレス・ポートにアクセスし、HTTPクライアント、 > サーバともにエラーが発生しないこと [root ＠ shared-rhel53-x8664 ~]# cat /etc/l7vs/sslproxy/sslproxy.target.cf | grep endpoint recv_endpoint = "0.0.0.0:443" target_endpoint = "192.168.10.11:80"" [root ＠ local_web02 tmp]# wget https://shared-rhel53-x8664:443/index.html --no-check-certificate --03:14:42-- https://shared-rhel53-x8664/index.html shared-rhel53-x8664 をDNSに問いあわせています... 192.168.10.97 shared-rhel53-x8664|192.168.10.97|:443 に接続しています... 接続しました。警告: cannot verify shared-rhel53-x8664's certificate, issued by `/C=AU/ST=NSW/L=Sydney/O=asio': Self-signed certificate encountered. 警告: 証明書に記載されている名前 `' とホスト名 `shared-rhel53-x8664' が一致しません HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 69 [text/html] Saving to: `index.html' 100%[===========================================================>] 69 --.-K/s in 0s 03:14:42 (135 KB/s) - `index.html' を保存しました [69/69] [root ＠ local_web02 tmp]# > (5) 以下の設定を追加し、リクエストに X-Forwarded-For を追加 > して、リアルサーバ側でクライアント IP を確認できること。 > > http_request_header = "add:X-Forwarded-For:%{CLIENT_ADDR}" > > リアルサーバ側は環境変数を出力するCGIにアクセスする or ア > クセスログにX-Forwarded-For を出力するようhttpd.conf を設 > 定するなどして確認してください。 [root ＠ shared-rhel53-x8664 ~]# cat /etc/l7vs/sslproxy/sslproxy.target.cf | grep "add:X-Forwarded-For" http_request_header = "add:X-Forwarded-For:%{CLIENT_ADDR}" [root ＠ local_web01 ~]# cat /etc/httpd/conf/httpd.conf | grep X-Forwarded-For LogFormat "%{X-Forwarded-For}i" xf [root ＠ local_web01 ~]# cat /etc/httpd/conf/httpd.conf | grep xf_log CustomLog logs/xf_log xf [root ＠ local_web01 ~]# tail -f /var/log/httpd/xf_log 192.168.10.12 192.168.10.12 192.168.10.12 [root ＠ local_web01 ~]# > (6) 以下の設定を追加して HTML のコンテンツにアクセスし、レス > ポンスの Content-type が text/plain になること。 > > http_response_header = "replace:Content-Type:html:plain" > > Live HTTP Headers や ieHTTPheaders などのHTTPリクエストヘッ > ダを確認できるツールをブラウザに導入して確認してください。 [root ＠ shared-rhel53-x8664 ~]# cat /etc/l7vs/sslproxy/sslproxy.target.cf | grep "Content-Type:html:plain" http_response_header = "replace:Content-Type:html:plain" [root ＠ shared-rhel53-x8664 ~]# [root ＠ local_web02 tmp]# wget https://shared-rhel53-x8664:443/index.html --no-check-certificate --save-headers --03:19:46-- https://shared-rhel53-x8664/index.html shared-rhel53-x8664 をDNSに問いあわせています... 192.168.10.97 shared-rhel53-x8664|192.168.10.97|:443 に接続しています... 接続しました。警告: cannot verify shared-rhel53-x8664's certificate, issued by `/C=AU/ST=NSW/L=Sydney/O=asio': Self-signed certificate encountered. 警告: 証明書に記載されている名前 `' とホスト名 `shared-rhel53-x8664' が一致しません HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 69 [text/plain] Saving to: `index.html' 100%[===========================================================>] 69 --.-K/s in 0s 03:19:46 (13.2 MB/s) - `index.html' を保存しました [69/69] [root ＠ local_web02 tmp]# [root ＠ local_web02 tmp]# cat index.html HTTP/1.1 200 OK Date: Fri, 21 Aug 2009 18:18:45 GMT Server: Apache/2.2.3 (Red Hat) Last-Modified: Wed, 19 Aug 2009 16:19:40 GMT Etag: "2006ed-45-471810080bf00" Accept-Ranges: bytes Content-Length: 69 Connection: close Content-Type: text/plain; charset=UTF-8 1st server. ultramonkey [root ＠ local_web02 tmp]# > (7) sslproxyadm stop で停止できること [root ＠ shared-rhel53-x8664 ~]# sslproxyadm stop [root ＠ shared-rhel53-x8664 ~]# sslproxyadm status ----- Print SSLproxyadm status start ----- [ Common Data ] Common config file : /etc/l7vs/sslproxy/sslproxyadm.cf Output log file : /var/log/l7vs/sslproxy/sslproxyadm.log Output log level : warn Log rotate config file : /etc/logrotate.d/sslproxy Log rotate status file : /var/lib/logrotate.status [ Target Data ] TargetID : target_1 Config file : /etc/l7vs/sslproxy/sslproxy.target.cf Process status : Normal. Execute status : Stopped. [ Unknown SSLproxy process ] Process nothing. ----- Print SSLproxyadm status end ----- > (8) アンインストールできること > ・rpm -e でアンインストール時，コマンドの戻り値が 0 になる [root ＠ shared-rhel53-x8664 PKG]# rpm -e sslproxy [root ＠ shared-rhel53-x8664 PKG]# echo $? 0 [root ＠ shared-rhel53-x8664 PKG]# rpm -qa sslproxy [root ＠ shared-rhel53-x8664 PKG]# > > 以上です。 > 【追加】 > sslproxy.target.cf の > session_cache = "off", session_cache = "on" それぞれに対して > 以下のコマンドを実施 > > # openssl s_client -host IP-ADDR -port PORT -reconnect 2>&1 | egrep -i "(Session-ID:|^reuse|^new|connect)" > > （session_cache = "on" の場合） > 最初が New で残り 5 回が Reused になっていること、 > Session-ID が同じことを確認。 > > （session_cache = "off" の場合） > 全ての接続が New で、Session-ID が表示されないことを確認。 [root ＠ shared-rhel53-x8664 ~]# cat /etc/l7vs/sslproxy/sslproxy.target.cf | grep "session_cache =" session_cache = "on" [root ＠ shared-rhel53-x8664 ~]# openssl s_client -host 127.0.0.1 -port 443 -reconnect 2>&1 | egrep -i "(Session-ID:|^reuse|^new|connect)" CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: 6A0674A7747C991249E336D00C6F7B7D400E3C4B231F626A51A8F7315EA9EA12 drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: 6A0674A7747C991249E336D00C6F7B7D400E3C4B231F626A51A8F7315EA9EA12 drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: 6A0674A7747C991249E336D00C6F7B7D400E3C4B231F626A51A8F7315EA9EA12 drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: 6A0674A7747C991249E336D00C6F7B7D400E3C4B231F626A51A8F7315EA9EA12 drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: 6A0674A7747C991249E336D00C6F7B7D400E3C4B231F626A51A8F7315EA9EA12 drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: 6A0674A7747C991249E336D00C6F7B7D400E3C4B231F626A51A8F7315EA9EA12 [root ＠ shared-rhel53-x8664 ~]# [root ＠ shared-rhel53-x8664 ~]# cat /etc/l7vs/sslproxy/sslproxy.target.cf | grep "session_cache =" session_cache = "off" [root ＠ shared-rhel53-x8664 ~]# openssl s_client -host 127.0.0.1 -port 443 -reconnect 2>&1 | egrep -i "(Session-ID:|^reuse|^new|connect)" CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: [root ＠ shared-rhel53-x8664 ~]# -------------------------------------------------- 以上です。 -- Jun Sugiura From n.nakai ＠ sdy.co.jp Fri Aug 21 18:47:13 2009 From: n.nakai ＠ sdy.co.jp (=?ISO-2022-JP?B?GyRCQ2Y1bzd7NVcbKEI=?=) Date: Fri, 21 Aug 2009 18:47:13 +0900 Subject: [Ultramonkey-l7-develop 503] Re: =?iso-2022-jp?b?TVEbJEIkSBsoQlJQUxskQiRYJE4lZiE8JTYhPDZ1GyhC?= =?iso-2022-jp?b?GyRCNFYkKyRpJE4lIiVXJW0hPCVBJEskRCQkJEYbKEI=?= In-Reply-To: References: <4A8D3F9F.8000101@sdy.co.jp> Message-ID: <4A8E6D21.1070103@sdy.co.jp> 中居＠明日も通院… >> 方式的には「CPUに結びついたThreadPoolを持つ」のが特色でしょうか。 > 論理 CPU の数だけスレッドプールを作って，各々のスレッドプールに > 各ソケットを処理するスレッドをプーリングする，という思想で良いでしょうか． > sched_setaffinity に tid と mask を渡して，擬似的に > スレッドプールを作るような・・・．擬似的ではないですね。これはsched_setaffity()を発行してthread所属のCPUをその都度移動するとコストが非常にかかるため、最初にCPUごとにThreadPoolを作成する必要があります。 (どれぐらいコストがかかるかは測定していません…) > wiki にまとめて頂いている情報を整理すると・・・ > > ・UM-L7 起動時に必要な情報 > > - MultiQueuing の使用可否（使うか否かではなく，使えるか否か） > → スレッドプールを分散させるか否かの判断をするために必要． > > - Queue の総数 > → どれだけスレッドプールを作れるかを判断するために必要． > NIC の queue の数が CPU 数を下回る可能性があるため． > > e.g.: i82575 だと RX も TX も 4 本しかないので，8cores 以上だと > 一杯一杯に使えない． > > - CPU 数 > → いくつスレッドプールを作るかを決めるために必要． > - ハッシュ関数のインタフェイス > → リアルサーバに一番近い > どんな情報が必要かも含む．これらはCPUにくくりついたThreadPoolを作成するために必要です。 MQが有効/無効ではThreadPool自体を1本かN本かの動作切り替え自体に影響しますし。また、RPSとの兼ね合いが今考慮されていませんのでこの部分は考慮すべきかと。 > ・コネクションの処理にあたって必要な情報 > > - FD に紐付いた CPU > → FD を握っている CPU が持つスレッドプールを特定するために必要． > > - Queue 割り付けのハッシュ > → リアルサーバ通信用スレッドを起こすためにスレッドプールを > 特定するために必要．このあたり難しいのですが、RPSにしろMQにしろ必要なのはCPUMaskです。そして、CPUMaskを得るための情報は・FD ・sockaddr_strage ・MACアドレス・etc... と、存在します。 > 方式の面では，先日話したように，起動時にのみ必要な情報は sysfs などで， > コネクション処理で必要な情報については ioctl などで取ってくるように > した方が良いかもしれません． > ＃ sockaddr_storage を内包する構造を新しく定義するとか必要？ ioctlもしくは新しいAPIになるかと思います。 sysfsを開くにはOpenしてreadしてテキストをパースして…と重たい処理が続きます。それがコネクションが発生するごとに行うのは流石にオーバーコストかと思います。 > 必要な情報についてもう少し精査しましょう．そうですね。自分自身にもブレイクダウン出来ていない部分などがありますので (RPSのsend部分など) ご協力お願いいたします。 -- _____________________________________________ 中居憲久[Norihisa NAKAI] n.nakai ＠ sdy.co.jp 株式会社SDY tel:047-401-7210/fax:047-401-7207 From h.okada ＠ sdy.co.jp Fri Aug 21 18:50:40 2009 From: h.okada ＠ sdy.co.jp (Hajime Okada) Date: Fri, 21 Aug 2009 18:50:40 +0900 Subject: [Ultramonkey-l7-develop 504] Re: =?iso-2022-jp?b?TVEbJEIkSBsoQlJQUxskQiRYJE4lZiE8JTYhPDZ1GyhC?= =?iso-2022-jp?b?GyRCNFYkKyRpJE4lIiVXJW0hPCVBJEskRCQkJEYbKEI=?= In-Reply-To: References: <4A8D3F9F.8000101@sdy.co.jp> Message-ID: <4A8E6DF0.3080502@sdy.co.jp> 岡田です。 >> まず、MQやRPSに最大限対応すべくMultiThreadの設計をすると >> http://sourceforge.jp/projects/ultramonkey-l7/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%83%A2%E3%83%87%E3%83%AB >> このリンク先の説明になります。 >> 方式的には「CPUに結びついたThreadPoolを持つ」のが特色でしょうか。 > > 論理 CPU の数だけスレッドプールを作って，各々のスレッドプールに > 各ソケットを処理するスレッドをプーリングする，という思想で良いでしょうか．ここの部分は、キューの割当たっているCPUの数になると思います。ドライバの設定でキューの数が設定できます。 8CPUでキュー4つの設定にしている場合、キューの割当たるCPUは4つとなる。このとき作成するスレッドプールは4つ・・・になると思いますが、どうでしょうか？ > sched_setaffinity に tid と mask を渡して，擬似的に > スレッドプールを作るような・・・．スレッドプールオブジェクト(queue?vector?)のインスタンスをキューの数だけ作って、その中にスレッドオブジェクトを蓄える。スレッドオブジェクトの持っているスレッドは、sched_setaffinityでCPUを固定する。こんな感じになるかと思います。あと、上記リンクの中の下の図で、受信スレッドと送信スレッドが別のCPUで動いていますが、コア間のデータのやり取りを減らすため、送信スレッドが動くCPUと送信スレッドが動くCPUを同じにできれば、速度を追求できるのではないでしょうか？なので、ここで送信時のキューをユーザから設定できるようになれば(set_queueaffinity？)Goodではないでしょうか？ >> そして、タイトルにあるようにこの方式を実現するためにはkernelから情報を取 >> 得出来なければなりません。 >> その案を示しました。 >> http://sourceforge.jp/projects/ultramonkey-l7/wiki/KernelRequestL7vsd > > wiki にまとめて頂いている情報を整理すると・・・ > > ・UM-L7 起動時に必要な情報 > > - MultiQueuing の使用可否（使うか否かではなく，使えるか否か） > → スレッドプールを分散させるか否かの判断をするために必要． > > - Queue の総数 > → どれだけスレッドプールを作れるかを判断するために必要． > NIC の queue の数が CPU 数を下回る可能性があるため．上で書いていることは、ここにありましたね・・・失礼しました。 > > e.g.: i82575 だと RX も TX も 4 本しかないので，8cores 以上だと > 一杯一杯に使えない． > > - CPU 数 > → いくつスレッドプールを作るかを決めるために必要．キューの数と関連しますね。 > - ハッシュ関数のインタフェイス > → リアルサーバに一番近い > どんな情報が必要かも含む．？？？すいません、ここがちょっとわからないです。送信時のキュー割り当てについてでしょうか？下記のQueue 割り付けのハッシュ用ですか？ > ・コネクションの処理にあたって必要な情報 > > - FD に紐付いた CPU > → FD を握っている CPU が持つスレッドプールを特定するために必要． > > - Queue 割り付けのハッシュ > → リアルサーバ通信用スレッドを起こすためにスレッドプールを > 特定するために必要． > 宜しくお願いします。 -- /*======================== H.Okada / 岡田　創 h.okada ＠ sdy.co.jp 株式会社SDY ========================*/ From n.nakai ＠ sdy.co.jp Fri Aug 21 18:55:10 2009 From: n.nakai ＠ sdy.co.jp (=?UTF-8?B?5Lit5bGF5oay5LmF?=) Date: Fri, 21 Aug 2009 18:55:10 +0900 Subject: [Ultramonkey-l7-develop 505] Re: =?utf-8?b?TVHjgahSUFPjgbjjga7jg6bjg7zjgrbjg7znqbrplpPjgYs=?= =?utf-8?b?44KJ44Gu44Ki44OX44Ot44O844OB44Gr44Gk44GE44Gm?= In-Reply-To: <4A8E5FE8.70805@oss.ntt.co.jp> References: <4A8D3F9F.8000101@sdy.co.jp> <4A8E5FE8.70805@oss.ntt.co.jp> Message-ID: <4A8E6EFE.3000909@sdy.co.jp> TO:フェルナンド様 CC:皆様中居です。お世話になっております。どうぞよろしくお願いいたします。こちらもまだGoogleのパッチを全て見切れていないので、送信時などの処理等不明瞭な部分が存在ますので、UpDateするかもしれません。お手数掛けると思いますが、どうぞよろしくお願いします。 > 中居様 > > いつもお世話になっております。 > フェルナンドです。 > > メールをありがとうございました。 > > 今ちょっとバタバタしていますが、今週末下記の資料を > ちゃんと拝見してフィードバックさせて戴こうと思って > おります。 > > 以上、宜しくお願い致します。 > > 中居憲久さんは書きました: >> TO:フェルナンド様、竹林様、中野様、岡田様 >> CC:Monkey-develop >> >> 中居です。 >> お疲れ様です。 >> >> MultiQueueそしてRPSやFlowDirectorなどlinuxを取り巻くネットワーク環境は >> 今非常に速い速度で進化しております。 >> Montrealで行われたLinuxSimposiumでフェルナンド様と話をしていたMonkey側か >> らkernel側へのリクエスト用件をまとめました。 >> >> まず、MQやRPSに最大限対応すべくMultiThreadの設計をすると >> http://sourceforge.jp/projects/ultramonkey-l7/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%83%A2%E3%83%87%E3%83%AB >> >> このリンク先の説明になります。 >> 方式的には「CPUに結びついたThreadPoolを持つ」のが特色でしょうか。 >> >> そして、タイトルにあるようにこの方式を実現するためにはkernelから情報を取 >> 得出来なければなりません。 >> その案を示しました。 >> http://sourceforge.jp/projects/ultramonkey-l7/wiki/KernelRequestL7vsd >> >> 上記は中居が意識している部分でまとめました。 >> 足りない部分、もしくはもっとよい方法が存在する部分、 >> 間違っている部分(RPSの送信側については調査が不十分ですし、 >> MultiQueue+RPSも出来ますが動きをまだ考え切れていません)等がまだ残ってい >> ると考えられます。 >> >> 一度目を通していただき、些細なことでかまいませんので >> コメントをいただけますと幸いかと思います。 >> >> どうぞよろしくお願いします。 > -- _____________________________________________ 中居憲久[Norihisa NAKAI] n.nakai ＠ sdy.co.jp 株式会社SDY tel:047-401-7210/fax:047-401-7207 From sugiura.jun ＠ oss.ntt.co.jp Fri Aug 21 19:16:47 2009 From: sugiura.jun ＠ oss.ntt.co.jp (Jun Sugiura) Date: Fri, 21 Aug 2009 19:16:47 +0900 Subject: [Ultramonkey-l7-develop 506] Re: =?iso-2022-jp?b?GyRCJWolaiE8JTlBMDghPlo3azJMSnM5cCFKGyhCaTM4?= =?iso-2022-jp?b?NhskQiFLGyhC?= In-Reply-To: <20090820162957.FEB9.9A97E586@oss.ntt.co.jp> References: <20090820155243.FEB3.9A97E586@oss.ntt.co.jp> <20090820162957.FEB9.9A97E586@oss.ntt.co.jp> Message-ID: <20090821191033.7419.9A97E586@oss.ntt.co.jp> 杉浦です。 sslproxy-1.0.2-0.rc3.i386.rpmを使用して sslproxy の追加検証及び一部再実施し、特に問題のない事を確認しました。また、ultramonkey-l7 の検証にて設定値が項目と異なっていたものが１件ありましたので再実施しております。　※検証内容は下記を参照ください。 ------------------------------------------------- > ============================================================ > >> ultramonkey-l7 > ============================================================ > (15) IP モジュールのタイムアウト確認 > > l7directord.cf に > > virtual=0.0.0.0:80 > real=xxx.xxx.xxx.xxx:80 > real=yyy.yyy.yyy.yyy:80 > module=ip --timeout 5 > > を設定して起動し、l7vsadm -V -n でリアルサーバが 2 つ、 > --timeout 5 が設定されていることを確認する。 > > 適当なクライアントから 5 秒間隔以内で連続アクセスして > 同一のサーバに接続されることを確認する。 > keep-alive オンだとよくわからないので > keep-alive オフで確認してください。 > l7vsadm で接続数が偏って増加しているのを確認するのもありです。 > > 次に 5 秒以上間隔をあけてからアクセスすると、もう片方の > サーバに接続されることを確認してください。 [root ＠ local-RHEL53x86 ~]# l7vsadm -V -n 　・　・　・ Prot LocalAddress:Port ProtoMod Scheduler Reschedule Protomod_opt_string SorryAddress:Port Sorry_cc Sorry_flag QoS-up Throughput-up QoS-down Throughput-down -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 0.0.0.0:80 ip rr 0 --timeout 5 192.168.0.53:8080 1000 0 100000000 0 100000000 0 -> 192.168.10.11:80 Masq 1 0 0 -> 192.168.10.12:80 Masq 2 0 0 [root ＠ local-RHEL53x86 ~]# date;l7vsadm 2009年 8月 21日金曜日 19:01:49 JST Layer-7 Virtual Server version 2.1.3-0.rc1 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 0.0.0.0:http ip rr -> 192.168.10.11:http Masq 1 0 5 -> 192.168.10.12:http Masq 2 0 0 [root ＠ local-RHEL53x86 ~]# date;l7vsadm 2009年 8月 21日金曜日 19:01:54 JST Layer-7 Virtual Server version 2.1.3-0.rc1 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP 0.0.0.0:http ip rr -> 192.168.10.11:http Masq 1 0 5 -> 192.168.10.12:http Masq 2 0 1 [root ＠ local-RHEL53x86 ~]# > ============================================================ > >> sslproxy > ============================================================ > (3) sslproxyadm start で起動できること > (事前にsslproxy.target.cf の target_endpoint を適切に書 > き換えること) [root ＠ local-RHEL53x86 ~]# sslproxyadm start [root ＠ local-RHEL53x86 ~]# sslproxyadm status ----- Print SSLproxyadm status start ----- [ Common Data ] Common config file : /etc/l7vs/sslproxy/sslproxyadm.cf Output log file : /var/log/l7vs/sslproxy/sslproxyadm.log Output log level : warn Log rotate config file : /etc/logrotate.d/sslproxy Log rotate status file : /var/lib/logrotate.status [ Target Data ] TargetID : target_1 Config file : /etc/l7vs/sslproxy/sslproxy.target.cf Process status : Normal. Execute status : Starting. PID = 3002 [ Unknown SSLproxy process ] ----- Print SSLproxyadm status end ----- > (4) 待ち受けアドレス・ポートにアクセスし、HTTPクライアント、 > サーバともにエラーが発生しないこと [root ＠ local_web02 tmp]# wget https://local-RHEL53x86:443/index.html --no-check-certificate --04:02:22-- https://local-rhel53x86/index.html local-rhel53x86 をDNSに問いあわせています... 192.168.10.30 local-rhel53x86|192.168.10.30|:443 に接続しています... 接続しました。警告: cannot verify local-rhel53x86's certificate, issued by `/C=AU/ST=NSW/L=Sydney/O=asio': Self-signed certificate encountered. 警告: 証明書に記載されている名前 `' とホスト名 `local-rhel53x86' が一致しません HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 69 [text/html] Saving to: `index.html' 100%[===========================================================>] 69 --.-K/s in 0s 04:02:22 (16.5 MB/s) - `index.html' を保存しました [69/69] > (7) sslproxyadm stop で停止できること [root ＠ local-RHEL53x86 ~]# sslproxyadm stop [root ＠ local-RHEL53x86 ~]# sslproxyadm status ----- Print SSLproxyadm status start ----- [ Common Data ] Common config file : /etc/l7vs/sslproxy/sslproxyadm.cf Output log file : /var/log/l7vs/sslproxy/sslproxyadm.log Output log level : warn Log rotate config file : /etc/logrotate.d/sslproxy Log rotate status file : /var/lib/logrotate.status [ Target Data ] TargetID : target_1 Config file : /etc/l7vs/sslproxy/sslproxy.target.cf Process status : Normal. Execute status : Stopped. [ Unknown SSLproxy process ] Process nothing. ----- Print SSLproxyadm status end ----- > > 以上です。 > 【追加】 > sslproxy.target.cf の > session_cache = "off", session_cache = "on" それぞれに対して > 以下のコマンドを実施 > > # openssl s_client -host IP-ADDR -port PORT -reconnect 2>&1 | egrep -i "(Session-ID:|^reuse|^new|connect)" > > （session_cache = "on" の場合） > 最初が New で残り 5 回が Reused になっていること、 > Session-ID が同じことを確認。 > > （session_cache = "off" の場合） > 全ての接続が New で、Session-ID が表示されないことを確認。 [root ＠ local-RHEL53x86 PKG]# cat /etc/l7vs/sslproxy/sslproxy.target.cf | grep "session_cache =" session_cache = "on" [root ＠ local-RHEL53x86 PKG]# openssl s_client -host 127.0.0.1 -port 443 -reconnect 2>&1 | egrep -i "(Session-ID:|^reuse|^new|connect)" CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: 021BDC7E39F404748F9012C245BE963EC7831D29CAD559E4270CD41E52C0CDE1 drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: 021BDC7E39F404748F9012C245BE963EC7831D29CAD559E4270CD41E52C0CDE1 drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: 021BDC7E39F404748F9012C245BE963EC7831D29CAD559E4270CD41E52C0CDE1 drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: 021BDC7E39F404748F9012C245BE963EC7831D29CAD559E4270CD41E52C0CDE1 drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: 021BDC7E39F404748F9012C245BE963EC7831D29CAD559E4270CD41E52C0CDE1 drop connection and then reconnect CONNECTED(00000003) Reused, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: 021BDC7E39F404748F9012C245BE963EC7831D29CAD559E4270CD41E52C0CDE1 [root ＠ local-RHEL53x86 PKG]# [root ＠ local-RHEL53x86 PKG]# cat /etc/l7vs/sslproxy/sslproxy.target.cf | grep "session_cache =" session_cache = "off" [root ＠ local-RHEL53x86 PKG]# openssl s_client -host 127.0.0.1 -port 443 -reconnect 2>&1 | egrep -i "(Session-ID:|^reuse|^new|connect)" CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: drop connection and then reconnect CONNECTED(00000003) New, TLSv1/SSLv3, Cipher is AES256-SHA Session-ID: [root ＠ local-RHEL53x86 PKG]# ------------------------------------------------- 以上です。 -- Jun Sugiura From makoto ＠ kanon-net.jp Fri Aug 21 23:29:44 2009 From: makoto ＠ kanon-net.jp (Shinya TAKEBAYASHI) Date: Fri, 21 Aug 2009 23:29:44 +0900 Subject: [Ultramonkey-l7-develop 507] =?iso-2022-jp?b?RndkOiBVbHRyYW1vbmtleS1sNy1kZXZlbG9wIBskQiRYGyhC?= =?iso-2022-jp?b?GyRCJE4bKEIgZmVybmFuZG9Ab3NzLm50dC5jby5qcCA=?= =?iso-2022-jp?b?GyRCJE5FajlGJE8+NUcnJCxJLE1XJEckORsoQg==?= Message-ID: 竹林です．フェルナンドさんのメールが破棄されたようなので，転送します． ---------------------------------------------------------------- Shinya TAKEBAYASHI E-mail(private)： makoto ＠ kanon-net.jp GPG ID : FFD20D1F GPG FP : 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F ---------------------------------------------------------------- -------------- next part -------------- 添付メールを保管しました... 送信者: ultramonkey-l7-develop-owner ＠ lists.sourceforge.jp 件名: =?iso-2022-jp?b?VWx0cmFtb25rZXktbDctZGV2ZWxvcCAbJEIkWCROGyhCIGZl?= =?iso-2022-jp?b?cm5hbmRvQG9zcy5udHQuY28uanAgGyRCJE5FajlGJE8+NUcnJCwbKEI=?= =?iso-2022-jp?b?GyRCSSxNVyRHJDkbKEI=?= 日付: Fri, 21 Aug 2009 17:51:05 +0900 サイズ: 7453 バイト URL: http://lists.sourceforge.jp/mailman/archives/ultramonkey-l7-develop/attachments/20090821/10946608/attachment-0001.eml From makoto ＠ kanon-net.jp Fri Aug 21 23:54:32 2009 From: makoto ＠ kanon-net.jp (Shinya TAKEBAYASHI) Date: Fri, 21 Aug 2009 23:54:32 +0900 Subject: [Ultramonkey-l7-develop 508] Re: =?iso-2022-jp?b?TVEbJEIkSBsoQlJQUxskQiRYJE4lZiE8JTYhPDZ1GyhC?= =?iso-2022-jp?b?GyRCNFYkKyRpJE4lIiVXJW0hPCVBJEskRCQkJEYbKEI=?= In-Reply-To: <4A8E6D21.1070103@sdy.co.jp> References: <4A8D3F9F.8000101@sdy.co.jp> <4A8E6D21.1070103@sdy.co.jp> Message-ID: 竹林です． > >> 方式的には「CPUに結びついたThreadPoolを持つ」のが特色でしょうか。 > > 論理 CPU の数だけスレッドプールを作って，各々のスレッドプールに > > 各ソケットを処理するスレッドをプーリングする，という思想で良いでしょうか． > > sched_setaffinity に tid と mask を渡して，擬似的に > > スレッドプールを作るような・・・． > > 擬似的ではないですね。 > これはsched_setaffity()を発行してthread所属のCPUをその都度移動すると > コストが非常にかかるため、最初にCPUごとにThreadPoolを作成する必要があり > ます。 > (どれぐらいコストがかかるかは測定していません…) 意図していることは，中居さんの言うとおりです．表現が曖昧でした．すみません． > > ・コネクションの処理にあたって必要な情報 > > > > - FD に紐付いた CPU > > → FD を握っている CPU が持つスレッドプールを特定するために必要． > > > > - Queue 割り付けのハッシュ > > → リアルサーバ通信用スレッドを起こすためにスレッドプールを > > 特定するために必要． > > このあたり難しいのですが、RPSにしろMQにしろ必要なのはCPUMaskです。 > そして、CPUMaskを得るための情報は > ・FD > ・sockaddr_strage > ・MACアドレス > ・etc... > と、存在します。これはユーザ空間から渡してあげる情報ですね．まずは何が欲しいかを洗う必要がありますので， 1. 何が欲しいか → CPU mask 値 2. 現状では何が取ってこれるか → ？？？ 3. もし 2 に 1 を含まないのであれば，2 は 1 の代替として使えるものか → y/n？ 3.x 代替できなければ，新しいインタフェイスやデータ型をつくる → ？？？ 4. 取ってくるために与える情報は何か → FD，MAC アドレス，et.,al. の順に検討していく方が良いかと思います． > > 方式の面では，先日話したように，起動時にのみ必要な情報は sysfs などで， > > コネクション処理で必要な情報については ioctl などで取ってくるように > > した方が良いかもしれません． > > ＃ sockaddr_storage を内包する構造を新しく定義するとか必要？ > > ioctlもしくは新しいAPIになるかと思います。 > sysfsを開くにはOpenしてreadしてテキストをパースして…と重たい処理が続きます。 > それがコネクションが発生するごとに行うのは流石にオーバーコストかと思います。えぇ，文字列解析がネックになりますし，いちいち sysfs に吐き出させるためのコストも馬鹿にならないと思います．お行儀を考えた場合でも，ほぼ静的な値は sysfs に，動的な値は都度，何らかの軽いインタフェイスで取ってくるのが良いと思います．パフォーマンス比較のために，ダメもとでサンプルを書いてみても良いかもしれません． ---------------------------------------------------------------- Shinya TAKEBAYASHI E-mail(private)： makoto ＠ kanon-net.jp GPG ID : FFD20D1F GPG FP : 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F ----------------------------------------------------------------