[prev in list] [next in list] [prev in thread] [next in thread] 

List:       loadbalancing-l
Subject:    RE: RE: [load balancing] SLB - SSL Accelerator - Web I/O Accelerator evaluation
From:       "Andy Gravett" <ag () htl ! uk ! com>
Date:       2003-11-27 9:18:11
[Download RAW message or body]

Hi guys,

I thought I would just contribute a little on the use of Internel/external SSL \
offload.

I agree that external offload does make sence if you are planning to scale SSL \
greatly, but by adding more units you increase TCO, as there are more units to manage \
and configure, you add more points of failure (interlinks) and may as Pete pointed \
out not increase throughput(time will be added to a packet trip in the passing \
process), integrated daughter boards (made by broadcom in most cases)can be addressed \
at code level in an integrated product so if the code used is designed well and on \
the money! the SSL offload wil run at an optimum this also allows for other fancy \
stuff like compression of https traffic and frontend and backend SSL encrypt /decrypt \
and central managment of all SSL certs and keys etc.

And at the end of the day if SSL does scale massively you can always buy an bigger \
offloader and balance SSL off to the new unit.

Regards

Andy Gravett

Technical Director www.HTLSecure.net



-----Original Message-----
From: Pete Tenereillo [mailto:ptenereillo@adelphia.net]
Sent: 26 November 2003 18:32
To: lb-l@vegan.net
Subject: RE: RE: [load balancing] SLB - SSL Accelerator - Web I/O
Accelerator evaluation


> > SSL offload on the load balancer is maybe not the right idea as the CPU
of the Load balancer will be use as well....
So, even if you don't reach the "capacity" specified by the constructor, you
will degrade the overall performance of your load 
balancer!

That's the usual sales pitch for a load balancer vendor that does not offer
internal SSL offload capabilities, but it's not quite correct.

The "CPU" (or NP) of the load-balancer is not used for the SSL handshake
(which factors into TPS) in any of these mainstream products (the handshake
is roughly 1/2 the total overhead of SSL), and the CPU/NP is also not used
for bulk decryption (which factors into overall throughput) or even the SSL
proxy in most of them. Why? Because in the simplistic case Rainbow et. all
hardware are used at least for the handshake, and in the latter case there
is an entirely new board, usually but not always a Pentium/PC, stuffed
inside the load-balancer, aka "PC-on-a-blade". So in this latter case the
only original load-balancer resources that are shared are the power supply
and the fan and the external ports -- it is functionally no different than
an external SSL offload box.

For the couple of surviving load-balancing products that are Pentium/PC
based, yes SSL offload is just another software module sucking CPU away, but
that's not necessarily a bad thing. CPU is most often not the limiting
factor in PC based appliances anyway. It's interrupt servicing and the PCI
bus. Now because the SSL proxy is co-resident in these Pentium/PC based
load-balancers, there are substantial gains in overall system efficiency.
Interrupts or crossings of the PCI bus are not required to get packets from
the load-balancer module into the SSL module. In external SSL offload, or
even PC-on-a-blade "internal" SSL offload, interrupts and crossings of the
PCI bus are always required, both getting packets to the external box/board
and getting them back, and those interrupts suck away the CPU resources of
the Pentium/PC on the SSL offload box. Also, with a co-resident SSL offload
module, the load-balancer does not have to "load-balance" the external
box(es), so there are some minor savings on load-balancer processing power
there by using a truly internal SSL offload solution.

Now, as mentioned before, the one area where external SSL offload has the
clear advantage is flexibility/scalability. For example, if we call units of
L4-7 processing power "slibs" and units of SSL power "slobs", if you
determine that your site needs 10 slibs and 20 slobs, but the brand of
load-balancer you pick (based on features or attractive sales rep or
whatever reason) has internal SSL offload, is not necessarily the most
expensive model offered from that vendor, and has 10 slibs but only 5 slobs,
what do you do? You are short 15 slobs! Or what if the next bigger
load-balancer model from that vendor supports 20 slibs and 20 slobs? Now you
are getting enough slobs, but you have to pay for twice the slibs that you
need. Do you then erase your choice of load-balancer vendor (blowing your
chance for a date with the sales rep) and look for one that has exactly 10
slibs and 20 slobs? What if later on you add more users and more servers,
and therefore need more slobs? Or more slibs?

The fact that you can add an external SSL offload box (or 10) even if you
have a load-balancer with internal SSL offload mitigates this issue
somewhat, but not completely. You can usually get away with mixing and
matching, i.e. buy an SSL offload box from a different vendor than the
load-balancer or v.v., despite vendor's efforts to make it difficult to lock
you in, but if you purchase a combined solution and later need more "slibs"
you will have to throw out the internal SSL offload capability you paid for
when you upgrade.

The ability to scale (and even repair/replace) load-balancing and SSL
offload (or any other separable task for that matter) independently will
always provide the most flexibility.

But then again, the reason combined SLB and SSL offload platforms were
recently offered by most all vendors is that their customers asked for it -
so I guess I'll shut up now! :-/


Pete.

-----Original Message-----
From: owner-lb-l@vegan.net [mailto:owner-lb-l@vegan.net] On Behalf Of
renomaurice@voila.fr
Sent: Tuesday, November 25, 2003 11:59 PM
To: lb-l@vegan.net; lb-l@vegan.net
Subject: Re: RE: [load balancing] SLB - SSL Accelerator - Web I/O
Accelerator evaluation

Hello everybody,

Having the SSL offload on the load balancer is maybe not the right idea as
the CPU of the Load balancer will be use as well....
So, even if you don't reach the "capacity" specified by the constructor, you
will degrade the overall performance of your load 
balancer!

My 2cts,

Reno


> Message du 25/11/03 à 18h35
> De : David Royer <droyer@recruitsoft.com>
> A : lb-l@vegan.net
> Copie à : 
> Objet : RE: [load balancing] SLB - SSL Accelerator - Web I/O Accelerator
evaluation
> 
> From my point of view, anything can't beat having two separate systems.
> But if you are looking for scalability, I would go with F5 as load
> balancer and when the capacity gets reached, go with a stand-alone SSL
> offloader solution.
> 
> Anyway, everyone is lying on their specs for SSL.  There are so many
> ways to benchmark SSL...
> 
> My piece of advice, do not look for TPS.  This metric is kinda
> ridiculous, everybody is supporting more than enough.  Look for
> concurrent sessions capability and sustained SSL throughput.  Also go
> with a device that can do transparent loadbalancing, Layer2 packets
> rewriting (such as SonicWall products).
> 
> Peace man,
> 
> David
> 
> 	-----Original Message-----
> 	From: Diana Castro [mailto:DianaC@Radware.com] 
> 	Sent: Tuesday, November 25, 2003 4:34 AM
> 	To: 'lb-l@vegan.net'
> 	Subject: RE: [load balancing] SLB - SSL Accelerator - Web I/O
> Accelerator evaluation
> 	
> 	
> 
> 	Hi TD, 
> 
> 	Did you examine Radware's product line? 
> 
> 	Radware has a very large install base around the world. 
> 	Radware has a unique hardware SSL accelerator device called
> CertainT 100. 
> 	CertainT 100 in addition to being the strongest SSL accelerator
> in the market (the CertainT 100 L4 supports up to 7,000 TPS), can also
> act as a transaction accelerator using its built in software and
> hardware compression capabilities.
> 
> 	In addition to supporting compression, we also support HTTP/S
> connection multiplexing which greatly helps improve server performance.
> 
> 	CertainT 100 can work as a transparent proxy, meaning it
> maintains the client's original IP in the request it passes to the
> backend server. It can also work as a non-transparent server, meaning it
> approaches the backend server with its own IP address as the source IP
> of the request, in this operation mode we pass the client's IP address
> in the HTTP headers.
> 
> 	A bit about CertainT 100 feature set - 
> 
> 	*	Performance - 7000 TPS when performing SSL acceleration 
> 	*	Can either work as a transparent or non-transparent
> Proxy 
> 	*	Supports Backend encryption 
> 	*	Software and Hardware Compression 
> 	*	The ability to pass HTTP headers to the backend server 
> 	*	Comprehensive logging and statistics 
> 	*	Can be managed either via CLI (console and SSH) or
> secure WBM 
> 	*	Can work as an out-of-path SSL Sniffing device, meaning
> it receives SSL traffic decrypts it and then sends the decrypted SSL
> traffic to any IDS system.
> 		
> 
> 	Combined with Radware's WSD (Web Server Director) we provide a
> strong scalable SLB+SSL+Application Security and DoS protection. WSD
> supports a wide range of global server load balancing which allows to
> have a global solution which incorporates SLB and SSL acceleration. 
> 
> 	For more detailed information, you are welcome to contact us at
> any time. 
> 
> 
> 	With best regards 
> 
> 	Diana Castro 
> 	Radware Ltd. 
> 	Tel. : +972-3-766 8953 
> 	Fax.: +972-3-648 8662 
> 	Email: <mailto:dianac@radware.com> 
> 	<http://www.radware.com> 
> 
> 
> 
------------------------------------------

Faites un voeu et puis Voila ! www.voila.fr 



____________________
The Load Balancing Mailing List
Unsubscribe:    mailto:majordomo@vegan.net?body=unsubscribe%20lb-l
Archive:        http://vegan.net/lb/archive
LBDigest:       http://lbdigest.com
MRTG with SLB:  http://vegan.net/MRTG
Hosted by:	http://www.tokkisystems.com




____________________
The Load Balancing Mailing List
Unsubscribe:    mailto:majordomo@vegan.net?body=unsubscribe%20lb-l
Archive:        http://vegan.net/lb/archive
LBDigest:       http://lbdigest.com
MRTG with SLB:  http://vegan.net/MRTG
Hosted by:	http://www.tokkisystems.com


Thank you for evaluating the Spam Sleuth(tm) Enterprise.  Your
evaluation period has expired.  Please contact Blue Squirrel at
1-800-403-0925 (http://www.bluesquirrel.com) to license Spam Sleuth(tm)
Enterprise.  Your current configuration has 11 active users.


____________________
The Load Balancing Mailing List
Unsubscribe:    mailto:majordomo@vegan.net?body=unsubscribe%20lb-l
Archive:        http://vegan.net/lb/archive
LBDigest:       http://lbdigest.com
MRTG with SLB:  http://vegan.net/MRTG
Hosted by:	http://www.tokkisystems.com


[prev in list] [next in list] [prev in thread] [next in thread]