SSLのロードバランス

1 ：浜崎あゆみ：2001/05/28(月) 17:26

SSLの通信をロードバランスさせようとしていますが
IEではSSL-IDがセッション中に変化するので×
クッキーはブラウザでOFFにしたら×
結局、ソースアドレスでやってもProxyからでてくるものは一つのアドレスでまとめられてしまうので
同じサーバに負荷がかかってしまう・・・。
現在のテクノロジーではどのように解決してるのでしょうか？
教えてください。

112 ：名無しさん＠負荷分散：2007/05/30(水) 20:45:34 ID:4s9jM0qA

１のレス見て他のレスはまったく読んでないので回答でてたら申し訳ないけど
SSL通信を分散且つセッション維持の要件があるのなら、
SSLアクセラレータ付き負荷分散機orSSLアクセラレータ（単体）＋負荷分散機（単体）を
買いなされ。
そして任意のセッションIDCookieに入れるか携帯端末含むならURLに埋め込んで
複合化通信を負荷分散機に読み込める形にして通信すればおｋ
SSLアクセラレータ付き負荷分散機なら高いけど、SSL通信を分散機で暗号化を複合化するから
setCookieだろうがhttpヘッダーだろうが装置内で消化できる

113 ：?：2007/05/31(木) 19:42:49 ID:???

>>111
具体的な製品をあげてみてよ

114 ：anon：2007/08/07(火) 21:03:46 ID:???

>>112は6年前の>>1のレスに回答してるな
ここまで間の開いたレスは初めて見た

115 ：anonymous@FNAfb-08p4-226.ppp11.odn.ad.jp：2007/08/17(金) 00:50:46 ID:4WQvxILd

BIG-IPか旧Alteonだろうな。

単体のSSLアクセラレータってあんま使わないきが。

116 ：aaa：2007/09/17(月) 00:54:16 ID:Z3gAw+wT

>>115
ArrayTMXってのはどう？
ご存知な方、利用実績のある方いる？

117 ：名無しだよもん＠カラアゲうまうま：2007/12/23(日) 15:12:41 ID:???

>>112の後者の構成でArrayTMX使ってるけど
ファームウェアの不具合が酷かった。

一度構成固めてあと触らないなら構わないかも。

118 ：anonymous@softbank219200036086.bbtec.net：2008/03/25(火) 21:36:55 ID:???

たった2台のxSeriesの負荷分散用に
ServerIron4G売りつけるのはやめようよ。

lvs+heartbeatで仮想IP構成で十分だよ。
http://www.linuxvirtualserver.org/

119 ：anonymous@softbank219200039066.bbtec.net：2008/07/22(火) 11:10:50 ID:???

FoundryはBrocadeに買収されることに同意しました。

120 ：anonymous@118x240x100x162.ap118.gyao.ne.jp：2008/07/31(木) 04:30:13 ID:HHCQrCDx

array、foundry、alteon、radware、f5などで一番高いヤツにSSL付のがありんす。

セッション維持はSSLアクセラレーター付ロードバランサでやるか、アクセラレーターをロードバランサ
の前に付ける方法が一般的なんでしょうか？

L4ロードバランサでセッション維持機能の無いもの（バカバランサ）を使い、
サーバー間でセッションを複製するという方法を取ったほうが安くできるのではないかと思うのです。

121 ：anonymous@softbank219019220034.bbtec.net：2008/08/03(日) 10:30:22 ID:xSp5Csh/

>>417
ホンダのミニバン
ていゆかていじゅうしん

122 ：anonymous@eatkyo073134.adsl.ppp.infoweb.ne.jp：2008/09/16(火) 00:56:32 ID:mK2/4lG1

>>120
他は知らんが
ｆ５は普通にセッション維持できるけど
SSL複合しなくても・・・

123 ：_：2008/09/17(水) 02:34:18 ID:???

>>120
LBをSSL対応品にするか、LBの前段にSSLアクセラレータをいれるかしないと、負荷分散装置を通るときに
SSL暗号化を解除できない。そうすっと、パーシステンス/スティッキーの方式として事実上、SSL session ID
とソースIPくらいしか選べなくなるんじゃね。
SSL session ID方式は「一部ブラウザがSSL session IDを頻繁に再ネゴシエートする」って問題があったので、
個人的には避けたい。
現行バージョンのメジャーブラウザは問題ないはずだけど、未来を含めて絶対の保証はされないだろうし。

システム仕様で完全固定IPのみを相手にするという絶対的な保証があるなら、ソースID対応でなんとかなる。
ていうかそのほうが楽だ。

んで、サーバシステム側で「いつ別の物理サーバに振り分けられても問題ないような」構造にするのも手だ‥
ただし、アプリが状態の遷移を完全に把握して設計されていて、実装も問題なく、性能上の影響も一切生じず、
セキュリティ的な懸念もあり得ない、というのなら、だが。

個人的経験で言えば、その手の方法は動作試験以降が大変だ。
まれにアプリ的な動作が妙になったりで、「LBが悪いんだろう！てか頼むからそういって下さい！」と詰め寄ら
れたりとか。んでどこに問題があるのか切り分けが面倒だとか。(苦笑

個人的経験では、その手の案は「目先の小銭を節約する代わりに、実装と運用を無駄に複雑にする選択」と
言わざるを得ない。


「必要なのはサービスの可用性であり、トラフィック総量は少ないから負荷分散は不要」という要件でなら、
負荷分散を行わず、トラフィックの振り分け先は常に1台。主系サーバが落ちたら、トラフィックを副系サーバ
に振り分ける、みたいな設計もありだな。これならL4パーシステンスしかできないLBでもあまり問題ない。

124 ：anonymous：2008/09/19(金) 23:49:13 ID:???

ウチはこれで、SSLアクセラレータとL7負荷分散を入れてます。
ttp://fenics.fujitsu.com/products/ipcom/products/lineup/ipcom_ex_lb.html