La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
NAS, serveurs et micro-serveurs => Discussion démarrée par: kgersen le 26 novembre 2019 à 22:24:01
-
Une vidéo tres intéressante (mais un peu technique vers le milieu) sur les serveurs video de Netflix:
Ils utilisent du FreeBSD et grace a des optis cherchent a atteindre 200 Gbps (avec TLS) en sortie par serveur. Une des raisons de maximiser le flux par serveur est la rareté des IPv4.
les slides: https://people.freebsd.org/~gallatin/talks/euro2019.pdf
la vidéo: https://www.youtube.com/watch?v=8NSzkYSX5nY
-
Le NUMA c'est un peu la hantise des gens qui font du calcul haute performance (ce qui est mon cas), même si ça se gère plutôt bien une fois qu'on a compris le principe.
Autant c'est hyper-connu dans ce domaine autant c'est la première fois que j'en entends parler dans un contexte plus serveurs/réseaux.
Ils ont clairement des serveurs dont les configurations matérielles commencent à devenir très proches des nœuds d'un super-calculateur.
-
Dans le web aussi on optimise nos serveurs vis à vis de NUMA :-)
Enfin moi c'est ce que j'ai fais il fut un temps (numactl etc... , mais sous Linux par contre).
Si on veut qu'un serveur puisse servir un max de clients, à un moment donné , on est forcément confronté à de l'optim d'archi von Neumann ^^
-
Désolé je suis un noob dans ce domaine, mais les noeuds NUMA c'est valable uniquement sur les archi Intel non?
Car les proco AMD threadripper ils ont bel et bien les 32 voir 64 core en direct et non pas via un noeud NUMA.
Pourquoi rester sur du Intel alors?
Cdt,
DamienC
-
Numa concernent les systèmes multiprocesseurs.
C'est-à-dire quand t'as plusieurs cpu sur la même carte mère
-
AMD fait du NUMA depuis l'Opteron.
Il faut bien voir que l'archi NUMA qui existait bien avant son introduction dans les archis x86 apporte des avantages en terme de performances pour certains types de traitements, par rapport aux bon vieux bus partagés ou Crossbar, générateurs de contentions quand on multiplie les cores.
Ceci à condition que ce soit correctement géré par l'OS/l'appli.
-
Numa concernent les systèmes multiprocesseurs.
C'est-à-dire quand t'as plusieurs cpu sur la même carte mère
Pas seulement, AMD comme Intel fournissent maintenant des sockets avec plusieurs noeud NUMA par socket (Intel 2, AMD 4).
-
Il me semblait pourtant avoir vu une vidéo de LinusTechTips sur Youtube avec deux proco AMD bien costaud, et il disait justement que le système voyait les deux CPU comme un seul et non pas via un noeud NUMA, bref je suis surement à la ramasse sur le sujet vous vous y connaissez bien mieux que moi, même si cela m'interesse énormement.
Cdt,
DamienC
-
Parfois tu as des paramètres du BIOS qui permettent de choisir si l'OS voit les nœuds NUMA "internes" à la puce.
En sachant que souvent l'effet NUMA est bien moins sensible à l'intérieur de la puce qu'à l'extérieur. Il faudrait que je refasse des tests avec notre machine actuelle pour voir comment elle se comporte (elle est bi-sockets avec en plus je pense un léger effet NUMA à l'intérieur de chaque socket).
Le pire qu'on ait vu c'était notre ancienne machine avec des nœuds de calcul quadri-sockets sans interconnexions directes croisées :
1 ---- 3
| |
2 ---- 4(pas de liens entre les sockets 1 et 4 et les sockets 2 et 3).
-
Les archis NUMA, 2- (Threadripper) et 4- (Epyc) nodes :
-
hum a relire quelques trucs, certains prétendent que l'archi Zen2 n'est pas NUMA car le controller de mémoire est unique et partagé par les chiplets (CCX).
-
Effectivement il semble que contrairement à Naples, sur Rome il n'y a plus qu'un NUMA Domain par socket, tout passe par l'IO die
-
a priori ils arrivent maintenant a pousser 400 Gbps avec le même hardware qu'avant...
https://people.freebsd.org/~gallatin/talks/euro2021.pdf
-
C'est marrant, il y a certains slides j'ai l'impression de voir une formation que je donne dans un contexte de calcul haute performance scientifique. ^^
-
a priori ils arrivent maintenant a pousser 400 Gbps avec le même hardware qu'avant...
https://people.freebsd.org/~gallatin/talks/euro2021.pdf
Je n'ai pas regardé si c'est le même hardware.
Mais ils arrivent à pousser 400 Gbps [c'est la vidéo qui va avec la présentation]
https://www.youtube.com/watch?v=_o-HcG8QxPc
-
Intéressant dis-donc 8)
-
a priori ils arrivent maintenant a pousser 400 Gbps avec le même hardware qu'avant...
https://people.freebsd.org/~gallatin/talks/euro2021.pdf
Si on compare ce qui peut l'être date à date comme par exemple la version de prod, c'est avec changement de matériel.
Mais ce qui est passionant plus que les nombres eux-mêmes est l'articulation de l'architecture sur 8 ans depuis le coup de maître de la "simple" réécriture d'un appel système.
Si ce sont les nombres qui vous accrochent, le dernier papier/vidéo vient avec déjà un clin d'oeil sur le 800Gb/s - pas si étonnant dans leur situation (marge sur charge cpu, maîtrise de la répartition de charge, avènement pcie 5 déjà exploitable, e.g. ConnectX-7 s'ils restent fidèles à Mellanox, ...)
-
Petite maj vers le 800gbit/s: https://people.freebsd.org/~gallatin/talks/euro2022.pdf
Etonnant de voir que cela reste du relativement matériel commun (serveur dell cpu amd epyc, stockage nvme Intel, Nvidia Mellanox ConnectX-6 Dx)
La présentation reprend assez largement les précédentes. Ce qui est nouveau, à la fin, mériterait d'être suivi en vidéo. Même si la problématique d'élargissement numa est bien exposée, le "comment" manque de détail.
-
Il y a une partie intéressante en slide 25, la partie kTLS
On envoie TLS en gestion au Kernel ( je l'ai implémenté pour la gestion TLS 1.3 sur une machine).
Cf un de mes posts sur TLS 1.3
-
Voici une autre vidéo présentée il y a 2 mois concernant les choix techniques faits par Netflix (pas encore regardé pour ma part) :
https://www.youtube.com/watch?v=q4TZxj-Dq7s
-
merci pour la vidéo. 40 minutes c'est long effectivement.
Je l'ai parcouru rapidement.
progrès récents: 100Gbps avec seulement 100w
ils confirment utiliser BBR mais ne parlent pas de QUIC.
La vidéo est axée sur leurs contributions a Freebsd et leur galere sur un bug, pas trop sur le réseau.