Reprise du message précédent :

j'ai pas suivi, c'est quoi comme voiture ?

C'est déjà pas mal, tu as compris au moins la moitié

Maintenant, tu peux relire mais cette fois avec la diagonale dans l'autre sens, ca ira tout de suite mieux

Yaisse, synchro de VM, au niveau de l'OS.

L'avantage que j'y vois, c'est qu'on puisse conserver la gestion de flux connectés (genre TCP), ce qui reste assez hard à faire aujourd'hui.

http://www.gcu.info/2008/07/reunion-du-grand-conseil/
 
l'article sur les perfs est juste parfait pour convaincre vos décideurs pressés

mouaif, c'est pas pour demain, a priori les checkpoint sont pas déclenchés sur évènements mais sont temporels, donc pas de possibilité de répliquer la stack TCP en temps réel, donc lors d'une bascule de VM suite à une panne, les numéros de séquence de la VM hot standby ne seront pas à jour dans la stack.
 
ou alors ils implémentent vraiment un mécanisme d'acquittements d'évènements entre la VM active et la VM standby sur un lien dédié comme décrit dans l'article, mais ça doit impacter très fortement les perfs... donc inutilisable sur de grosses infras

 
tu connais pfsync ?

j'ai édité.
 
Dans les FW stateful tu as le problème, d'ailleurs les numéros de séquence ne sont en général pas répliqués, ils maintiennent en général juste les quintuplets (prot, ip src, ip dst, port src, port dst), car sous une très forte charge avec beaucoup de connexions TCP vivantes, le lien de synchro exploserait... et avec un mécanisme de transmission de num de séquence entre l'unité active et standby avec un mécanisme d'acquittement entre les deux, bonjour la latence induite...
 
D'ailleurs bon nombre de load balancer ne sont pas stateful au niveau TCP, car vu le nombre de sessions/sec qu'ils doivent encaisser, c'est juste pas possible

 
ok
 
je pense que c'est un mécanisme à la pfsync. Sur un lien/réseau dédié ça supporte bien la charge (je te parle pas de remplacer un core router là hein) mais sur des archis de VM, même loadées je pense que ça ne pose pas de problèmes. Si tu m'offres des machines je veux bien faire des benchmarks

j'ai encore édité
 
par contre effectivement sur des infras pas forcément énormes, le problème de perfs ne se pose pas pour des équipements réseaux.
 
Par contre maintenir l'état complet de plusieurs VM entre deux machines physiques, je pense que les perfs seront très fortement impactées, car maintenir l'état d'une VM doit être bien plus lourd en terme de charge que de maintenir l'état d'une session TCP

edit de fourbe
 
les bigip c'est pas stateful ?

pour big ip je sais pas, les netscaler le sont avec d'énormes resrictions, chez cisco les ACE sont stateful mais ils recommandent un channel dédié au lien de synchro pour que la bande passante du lien de synchro ne soit pas perturbée par le trafic data normal sachant qu'ils recommandent le 10GE pour de gros débits
 
je me demande quelles est l'évolution de la charge CPU sous des tests de charge violents  

mais cisco si ça marchait ça se saurait
 
merci pour les infos

Plait-il ?

Et grandr, c'est pour les canards ?
 

Mais pourquoi le troisième cas seulement ?
 

Mais pourquoi pas
 

Raconte

Oh et puis dernz tiens !

Genre

Oui

L'espoir fait vivre

'soir les barbus

"temps réel", c'est une terminologie qui sied assez peu au monde ethernet/IP.

Ca dépend comment la chose est implémentée. Pour l'instant, les xennet sont des bridges, avec les frames qui passe d'un domU à un dom0 (et réciproquement) via page copy (ou flipping). Il peut y avoir acquittement au niveau des pages vers la VM secondaire avant d'envoyer/recevoir les ack.

En fait, les problèmes de perfs viennent des context switch + overhead dans le traitement de la frame, qui sont tres couteux. On attend de voir ce que donne les développements dans les IOMMU (tout récent d'intel, la doc que j'ai là est de mai 2007), pour pouvoir éviter de passer par le dom0.

Attention quand même, pour garder l'état d'une connexion TCP, ca implique de descendre très bas dans les couches, jusqu'au transport. Ici, c'est plutot mettre des pages en lecture seule, et valider des traps, pour des pages marquées lecture seule par exemple.

L'idée en soi n'est pas nouvelle: mettre un micro noyau pour gérer des noeuds de cluster, c'est pas la révolution. La chose vient surtout que ca se joue dans le contexte d'une architecture pénible à virtualiser, x86.

les réduves c'est mieux

chronyd vaincra

bon aller, je tente un dernz

majorité ou pas, tu tomberas quand même sous le détournement de mineurs...

c'est cela la connectivité 3G

preums

deuz

< COIN §§§§
 

Lut les barbus

grmph les barbus

 
En dehors de toute considération purement technique, un IS c'est un ensemble et le plus simple c'est quand même d'avoir des applications qui ont une gestion de plantages et de reprise.
 
D'ailleurs si je me rappel bien de mes cours de gestion de projet et de modélisation, c'est un truc qui devrait toujours être pris en compte.
 
Dans certains endroit ou j'ai bosser ça rentrait dans le minimum vitale pour faire valider une applis en prod, qu'elle soit capable de reprendre après une bascule cluster.
 
C'est beau de faire des trucs magnifiques sur les systèmes, mais la partie applicative est souvent bien plus simple à gérer

+1  

Du peu d'experience que j'ai sur les cluster (HACMP), quand il y a un problème, c'est toujours les scripts applicatifs qui merdent (qui a dit Oracle )

/zytra
 
 
VENDREDI §§§ /wark0

la même qu'actuellement mais moins km et age plus neuf à quelques détails près (couleur/finition/moteur différent)
petite toph de l'interieur :
http://membres.lycos.fr/rastazar/B [...] C04524.jpg

beuuuaaarhhh z'dredaÿ

edit: et j'ai pris mon aprem'

c'est qui qui a eu les points pour le topic de Laura

Ouais, pour changer quoi

Coucou !!! [:zytra:]

Salut les barbus