Netflix esettanulmány a FreeBSD Foundation-től

Címkék

Régóta ismert, hogy a Netflix komoly mértékben épít a FreeBSD-re. Amellett, hogy használja, vissza is juttat a nyílt forrású projekthez. Most egy esettanulmányból lehet megtudni, hogy a Netflix miért éppen a FreeBSD-t választotta CDN rendszere alapjául. Elolvasható itt.

Hozzászólások

Szerkesztve: 2020. 10. 14., sze – 13:44

Kozben Linux:
kTLS nem csak kernel -ben lehet, de a NIC-re is kitolhato ha tamogatja:
https://docs.mellanox.com/display/OFED510660/Kernel+Transport+Layer+Sec…
https://www.kernel.org/doc/html/latest/networking/tls-offload.html

Meglepo hogy csak 16TB -van egy netflix nodeban, habar az ujak es hirdettetek (most poplar today in <country name>) siman elfernek benne.

1822 ora ~ 4k -ban.

"we require a minimum of 5 Gbps of peak Netflix traffic per deployment site"
100TB/s a netflix total peak, vajon hany site ill. hany ilyen cache node van jelenleg a vilagon,
IMHO legalabb 10000 hely van ami tudja nyujtani amit netflix ker ,
gondolom nagy varsokba tobbet is raknak egy azon DC -be.

szerk:
Latom van 248TB -s valtozat is 40Gb/s, na arra mar fer film ;-)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Igen, de már régóta minden processzor is tartalmaz hardveres megoldást erre. Minden processzor ami AES-NI támogatással rendelkezik támogatja részben a TLS gyorsítását. Ilyen HW IP-k nagyon régóta elérhetőek és egy 10G vagyis 25/40/100 kártya árába nagyon belefér és bele is szokták tenni.

Lehet hogy benne van modjuk iSCSi hez, de nem feltlen van kitolva neked is sajat hasznaltra.

Linkelt kartya 200Gbe , it kitoltak.

EAS-t harware eleg jol egyszeruen es olcson tudja tolni,
De aes-ni ota CPU -n sem nagy mutatvany. typikusan 500-800MB/sec per cpu core meg van (nem bit , byte)

Csak 20 oldal, es tobb fele is le van irva:
https://www.amazon.com/Advanced-FPGA-Design-Architecture-Implementation…

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

ennek ugye az lenne a nagy elonye, hogy a static fajl tls atkuldesehez nemkell userspace-ben atlapatolni az adatot hogy ott cpu bekodolja, aztan vissza a halokatyanak. ha jol emlekszem, a sok intel bug fixnel pont ez az adatlapatolas szenvedett a legtobb teljesitmeny csokkenest. szal talan sokat dobna ha a kernelnek csak elo kell kaparnia az adatot ssd/nvme-rol, es mar tolhatja is ki netre.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

2400Mhz*2socket*6channel*8 wide ~ 230.4 GB/sec memory bandwith 10Gbyte*2*2 ki be talan nem oli meg,
intel-nek az L3 cache vs I/O ra van valami extra trukje is.

KB. 3*25GB/sec UPI link per cpu (CPU to CPU),
nem szuper gyors , de talan bele fer.
Nem csoda, hogy nemi NUMA twaek is elfert.

Lehet hogy egy modern gepen, manapsag bele se kezdenenek tweakelesbe, "vacak" 100G -ert,
es egy socketbol megoldanak.

sendfile(2) linux kTLS -nel is van.

A CPU bug valoban sokszor dragabba tette a rendszerhivasokat intel CPU-n,
de ha mondjuk 64k -kent mozgatod az csak 312500 syscall/sec (read+write),
ami 40 szalra leosztva nem olyan sok, 1k alatt adat meretnel mar huzos lene,
de ki hasznal 4k alattit.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.