|
PB sent me the attached write up about SSL accelarators,
based on his experience spec'ing them for his work. It has
a few of my questions embedded.
I'd be pleased if people could add/correct/whatever and I'll
put the merged output in the HOWTO. Since it's lengthly,
please post the minimum amount of the original in your
replies to the mailing list.
Thanks Joe
--
Joseph Mack PhD, Senior Systems Engineer, SAIC contractor
to the National Environmental Supercomputer Center,
ph# 919-541-0007, RTP, NC, USA. mailto:mack.joseph@xxxxxxx
SSL Acceleration & Load Balancers
I've been working with SSL accelarators and
have been thinking about using them with LVS.
After having Foundry, F5 and Cisco in here for a
technical review of their products, I can tell you LVS
has all the basic load balancing functionality that
they do. F5 uses BSD Unix, Cisco runs on Linux with
ASIC chips, and they have fancy GUI
and various additional functionality, but LVS has all
the same basic stuff.
Note: Red Hat is a Cisco customer, and uses Cisco
load balancing and ssl solution in-house (I assume),
rather than using their own Red Hat Advanced
Server + Piranha + SSL solution of their own which
would have helped all us RH Linux Piranha customers.
An SSL accelarator is a piece of software running either
on a separate box which is inserted into your
data stream, decrypting on the way to the server and
then re-encrypting on the way back to the client, or
running on a card with its own processor,
that's inserted into the server to do the same thing.
In simpler times we put SSL Certificates
(Verisign, Thawte, etc.) on the realservers, and
let the load balancer route the traffic to
the real servers where the SSL decryption is done.
https, e-mail protocols smtps, imaps, and pops are all
SSL Encryption oriented. Additionally, many new
applications today have joined the SSL bandwagon.
Now SSL decryption is CPU-intensive and adds actual
load on your real servers. Solution? Add more real
servers behind your load balancer, right? Yes and no.
Adding additional real servers behind your load
balancer to offset SSL decryption load is the
intuitive solution, since that is what the purpose of
a load balancer is, to allow many real servers, and
lower the load to each. However some folks today
add what is gernerally called "SSL Accelerator" solution to the
mix, and remove as many SSL Certificates and SSL
decryption from the real servers and pre-process the
SSL Encrypted data stream before it hits the real
servers. In short SSL Accelerators decrypt the data,
then pass the decrypted data via clear-text (standard)
protocols (like http, smtp, imap, pop) to the real
servers.
eg for https, in a standard server, the decrypted https
is sent as clear text to the httpd on port 80.
Same for smtps -> smtp, imaps ->imap, pops-> pop, etc.
What happens to ssh?
I think because ssh is
using its own RSA keys (not SSL) on the server
the information is
encrypted all the way.
The point of the SSL accelarator is to reduce the
load on your server (which is now busy crypting, rather
than serving pages),
so that it can deliver more pages of data to clients
without changing your server setup.
However you could do the same thing by beefing up
you server (or putting an array of realservers behind an
LVS) without any change in software on your servers.
The problem then is one of cost.
The Ingrian and Sonicwall SSL boxes are in the multiple
10K$ range. The cards cost less, and other
stand-alone units that support fewer protocols (like
http/https only) cost a few thousand. Suits feel
better spending money when it is available (ie. an SSL
accelarator array will insure we don't need to spend more
money on 1 or 2 or 3 more realservers in the future).
So an SSL accelerator is aimed at non-technical, but
financially knowlegable managers, rather than techically
competent but financially naive computer people.
(When faced with the choice of going to an L7 load-balancer
or rewriting the application to be L4 friendly, the
suits will go for the slow and expensive L7 load-balancer,
while the programmers will re-write the application -
the choice depends on what you have at hand that you
understand).
You can have an SSL Accelerator without a load
balancer, but in order to have an array of them, you
want a load balancer. (Another choice is DNS round
robin, which several people, including Horms, have
found, is not a good way to go).
There are two main ways this passing the baton is
done. First, your load balancer can load balance all
data steams to a few of these SSL Accelerator units,
which decrypt any SSL encrypted data, and themselves
load balance all protocols to your real servers.
Second, your load balancer can load balance just the
SSL encrypted data streams to several SSL Accelerator
units, which after they decrypt the data, pass it back
to your load balancer as clear-text to be routed by
your load balancer as non-encrupted data over standard
protocols to your real servers.
SSL Accelerators are available as stand alone units
(you would normally buy several and make an array of
them) or as SSL Accelerator CARDS which plug into your
real servers to speed them up with regard to SSL
decruption (which is yet another solution).
In principle you could separate out the
SSL handingly from a linux server and
run it on a separate box to make a linux only
SSL accelarator box.
The natural people to do this would be the mod_ssl
people, but they
are supporting linux compatible SSL hardware
(eg cards that use the Broadcom chipset)
via the "OpenSSL engine" feature.
(see the mod_ssl mailing list archives
http://marc.theaimsgroup.com/?l=apache-modssl&r=1&w=2)
This will allow you to build a
SSL Accelorator Linux box
or to beef up your realserver with a
Broadcom card in your Linux LVS load balancer.
Since the extra processing is now on a separate
processor, in principle this should not add a lot
of extra load to your realserver.
Ingrian and Sonicwall
are a couple fairly expensive SSL Accelorator
solutions which support all the protocols you need.
Broadcom makes the card you can add to your real
servers. There are other brands which make less
expensive SSL Accerlorators that support only https
(web) protocol.
The information from most vendors is vendor-speak,
however Ingrian has some white papers.
http://www.ingrian.com/resources/index.html#wp
I peronally called Ingrian and found them to be
extremely TECHNICALLY helpful (more than I could
understand myself). They seemed willing to help me
even though I told them I use Piranha/LVS (and not
Foundry their partner). I did not find any level of
open-source style detail on SSL
Acceleration/decruption. Got all my info from the
load balancer companies, Ingrian, and white papers.
I don't know how an SSL accelarator box/card works.
Presumably several levels are involved.
o The box has to get the packets
One of the two methods (called "one arm config")
you have the load balancer route only SSL-bound
protocals (ie. https, imaps, smtps, etc.)
to the SSL accelerator.
o for a card, it has to grab the packets off
the PCI bus. (Anyone know how this is done?).
o the SSL accelarator has to keep track
of session data etc.
The end result is that the box/card
takes the SSL encrypted form of the data, decrypts it to clear text,
and shoots it out like it was never encrypted.
Some SSL accelarators have load balancing
built-in (eg Ingrian)o. But not all.
The standard "one arm config" does NOT require it.
You use your own load balancer, and send SSL encrypted
data to your SSL Accelerators, then they output
decrypted clear text data sending it back to the load
balancer for routing to the real servers.
Only Ingrian mentioned/recommended that they can also
do load balancing.
For LVS-DR, how does the packet
stream returning from the realservers
get re-crypted? Or can't you use LVS-DR?
Good question. The load balancer companies talk about
the decrypted clear text going to the real servers,
but do not recall a dicussion about going back out
again. I don't know how to answer that.
Peter Baitz
|
