[zorp-hu] ssh, https

[Attila Nagy]

Balazs Scheidler wrote:
> ez milyen openssl, milyen gcc-vel forditva? esetleg disztro? nalam
> nagyjabol negyedennyi jon ki (PIV 3GHz, openssl 0.9.7e, Debian sarge):
Xeon:
FreeBSD 5.4
OpenSSL 0.9.7e 25 Oct 2004
gcc version 3.4.2 [FreeBSD] 20040728

Opteron:
FreeBSD 6.0
OpenSSL 0.9.7e 25 Oct 2004
gcc version 3.4.4 [FreeBSD] 20050518

Mindkét gép AMD64-es üzemmódban megy (azaz a Xeon EM64T, ahogy az Intel 
szeretné hívni).

>                   sign    verify    sign/s verify/s
> rsa  512 bits   0.0008s   0.0001s   1314.0  14458.4
> rsa 1024 bits   0.0038s   0.0002s    262.1   4719.6
> rsa 2048 bits   0.0232s   0.0007s     43.1   1417.8
> rsa 4096 bits   0.1592s   0.0025s      6.3    405.3
Az asztali gépem (2,8 GHz P4) is hasonlót tud:
                   sign    verify    sign/s verify/s
rsa  512 bits   0.0009s   0.0001s   1140.6  12345.8
rsa 1024 bits   0.0042s   0.0002s    236.6   4348.8
rsa 2048 bits   0.0254s   0.0008s     39.4   1325.1
rsa 4096 bits   0.1704s   0.0026s      5.9    378.1


> Ekkora kulonbseget nem indokol az orajel kulonbseg, bar a cache meret szamithat.
512 kB cache-sel rendelkező 3,06 GHz-es Xeon:
                   sign    verify    sign/s verify/s
rsa  512 bits   0.0008s   0.0001s   1268.6  13669.1
rsa 1024 bits   0.0039s   0.0002s    258.5   4820.7
rsa 2048 bits   0.0232s   0.0007s     43.1   1476.1
rsa 4096 bits   0.1563s   0.0024s      6.4    416.5

A te géped megveri (lehet, hogy FSB, vagy valami chipset mágia, vagy 
csak a FreeBSD ilyen gagyi? :).

>>Gondolom ti is végeztetek mérést ilyen kártyákkal. Mikor ajánljátok? 
>>Ajánljátok?
> Nagy mennyisegu SSL kapcsolatoknal igen, a gepnek eppen eleg dolga van a
> forgalom kezelesevel.
Az eddigi számok alapján nekem úgy tűnik, hogy alternatívája lehet a sok 
olcsó gép a sok olcsó gép+kriptokártya felállásnak.

Persze itt is a terhelési minta a meghatározó. Ahol sok 
kapcsolatfelépítés van, jó lehet a kártya, de ahol inkább adatmozgatás, 
azt kilapátolja a PC is.

>>Arra ott a második processzor. Ma már "fillérekért" lehet venni egy két 
>>processzoros dual core opteronos gépet, amely a fenti benchmark szerint 
>>olyan 4-6000 sign/s-et tudhat, persze csak ha ezzel foglalkozik...
> Azert altalanos celu op.rendszerekben nehez linearis skalazodast elerni
> tobb processzorra. Igazad lenne, ha a masodik processzor csak szamolna,
> ha viszont betolod egy Linux ala, akkor a processzorok kozti context
> switcheknek egy ido utan eleg nagy az overheadje.
Persze, a processzek közötti környezetváltás is rengeteg idő, főleg ha 
másik processzorra migrálja az OS. :)

A fenti probléma enyhíthető lenne kicsit, ha a kripto műveleteket külön 
thread/processz végezné, nem? Ebben az esetben gyakorlatilag 
megvalósítható lenne az is, hogy ezeket a processzeket egyes 
processzorra dedikálja a user, azokból pedig load balance-olt poolt építsen.
Végeztetek esetleg mérést arra nézve, hogy egy ilyen lehetőség mennyit 
segítene (a fentiekből azt feltételezem, hogy most a zorp nem külön 
végzi ezeket a műveleteket, így nem is lehet procit dedikálni alá)?

Ha jelentős lenne a különbség, sokat dobhatna a teljesítményen, főleg a 
mostani multicore-os CPU-k esetében.

>>Az nCiphernek ha jól látom vannak Ethernet kártyával egybeépített 
>>termékei is. Ezekről esetleg van valami tapasztalatotok? Itt megfelelő 
>>felépítés esetén ez a késleltetés kiiktatható.
> Nincs sajnos, de ez SSL-hez valoszinuleg nem illesztheto, csak
> IPSec-hez, ahol mar egy osszerakott csomagot kell titkositani. Az SSL
Persze, azt hiszem ezt már csak durva firmware hackkel lehetne 
megoldani. De erre is volt már példa. :)

> Az nForce 800-as az 100k forintos nagysagrend (max 200k, nem emlekszem
> pontosan), Ultra-t meg nem hasznaltunk.
Köszi.

>>Akkor ez az új kérdésem, ha még jó vagyok a válaszra. :)
>>Cache-elhetők ezek az SSL kapcsolatok?
> Elvileg igen.
Az mit jelent? Az apache-ban például van SSL session cache. Van ilyen a 
zorpban?

Jobbat kérdezek (ha van): van lehetőség arra, hogy mondjuk memcached-del 
ezt a session store-t több gépen is használhatóvá tegyük?

Teszemazt ha valódi load balancingot szeretnénk, nem pedig IP alapú 
stickys megoldást. (minden új kapcsolat mehet más zorpra, még ugyanarról 
az IP-ről is)

Lehet, hogy inkább doksit kellene olvasnom, de ha már így belejöttem, 
megkérdezem azt is, hogy a többi (ha van) session jellegű infó közös 
tárolására vizsgáltátok-e már egy ilyen elosztott tudás jellegű megoldás 
előnyeit?

Lehet, hogy teoretikus a kérdés, mert nem kezeltek ilyen infót, hülye 
vagyok a zorphoz, na. :)

-- 
Attila Nagy                                   e-mail: Attila.Nagy at fsn.hu
Adopt a directory on our free software   phone @work: +361 371 3536
server! http://www.fsn.hu/?f=brick             cell.: +3630 306 6758