|
Hello,
On Mon, 10 Mar 2003, Joseph Mack wrote:
> > I hoped to decrypt the packets on the director and then pass the decrypted
> > packets to the realserver via the LVS
>
> Julian,
> Can packets from an SSL accelerator listening on VIP:443 (but which
> the LVS is not forwarding) and presumably outputting to VIP:80, be routed to
> ip_vs code? Presumably this would have to be LVS-NAT to get the packets on
> the way back.
The SSL Accelerator cards I know allow user space processes (usually
many threads) to accelerate the handling of private keys. What I know
is that the normal traffic is still encrypted and decrypted from the
CPU(s).
OTOH, decryptying the SSL data in directors is used mostly
to modify the HTTP headers for cookie and scheduling purposes.
For other applications it can be for another reason. Even the HTTP stream
from the real servers is modified. So, I don't think LVS can play here.
Of course, it is possible to implement everything in such way so the
user space handling is avoided and all processing is moved in kernel
space: queues for SSL async processing, HTTP protocol handling, cookies,
just like ktcpvs works in kernel space to avoid memory copy.
I don't follow the SSL forums, so I don't know at what
stage is the kernel-level SSL acceleration. My experience shows
that the user-space model needs many threads just for private keys
to keep the accelerator busy and the rest is spent for CPU encryption
and decryption of the data. I don't know if this is true
for all cards. But even with accelerator, the using of SSL costs 3-4
times more than just the plain HTTP. My opinion is that this game is
useful only for cookie persistence. For other cases LVS can be used
in directors and the accelerators on the real servers - LVS forwards
TCP(:SSL:HTTP) at L4, the accel is used from user space as usually.
> Thanks JOe
Regards
--
Julian Anastasov <ja@xxxxxx>
|
