Reprise du message précédent :
Sinon, juste comme ça, t'as contacté ton CRI pour voir si ils étaient pas déjà équipé d'un SAN FC ou iSCSI ?

Ils ont du matos pour leurs serveurs. Un SAN global est prévu mais il n'y a pas de date, ce qui n'est jamais bon  
 
De toute facon, je testerai quelques baies, Dell en prête.

 
je confirme, pas de bonding vers le stockage

tu peux pousser des arguments ? parce que du 802.3ad ça aide pour les perfs

on est d'accord sur le bien fondé du truc, mais va dire ça aux supports des différents constructeurs de stockage qui font la gueule (j'ai deja eu : "mais de quoi vous me parlez là, ici on fait du stockage, hein, pas du réseau " ... bon d'accord, c'était en 2007 ) quand tu leur annonces que t'as du bonding, après chacun vois midi à sa porte.

Je me supporte moi même  

- Si y a du multipath, il va gérer tout seul le "un coup par tel port, un coup par l'autre".
- C'est plus dans la logique multipath/redondance
- Tu peux utiliser deux switchs différents pour faire du bonding ? (il me semblait que non, à cause des @mac, ou alors faut configurer les switchs de façon particulière, et dans le cas de SAN/multipath, il est plutot recommandé que les différents switches s'ignorent l'un et l'autre royalement - il me semble)
 
Bref c'est se rajouter des problèmes potentiels alors que ça n'apportera strictement rien d'après moi
 
Pis bon, avant de saturer un port Gb avec du iSCSI, sa baie de disque en SATA aura pris feu, si c'est pas le CPU de son initiator

 
yep, c'est tout le principe de dual-fabric, sinon tu te ramènes des spofs

Merci de confirmer maître, je serai bientôt prêt à prendre la relève

 
prêt tu es déjà  

Ah intéressant ! Merci des précisions !
 
Donc par serveur :
- 2 liens vers stockage en multipath
- 2 en bonding vers le lan (en load balancing ou équivalent)
- 1 eventuel pour la HA entre les deux serveurs ML350. Xenserver utilise heartbeat avec une petite LUN dédiée d'après ce que j'ai lu.

Avec un stack.

Et encore un plantage de VM en Lenny, ça me saoule
Celle-là n'a pas de FS en xfs, donc c'est pas ça le problème.
 
Et les forums de Cirtix Xen Server sont plein de retours de ce type, zero solutions, donc c'est pas la version open source le pb non plus.
 
Je vais tenter le passage de noyal en 2.6.32 (bye bye la migration ), et si ça solutionne pas le problème, ça va se finir en VMware cette histoire, ras-le-cul

Aurais tu essayé KVM ?

Ras le bol de l'Open Source qui marche pas

Ou alors j'installe des RedHat dans tous mes domU (le pb semble lié à Lenny + nvcpus >= 2)
Ou alors j'installe le noyau Etch dans mes domU Lenny
 
http://moblog.wiredwings.com/archi [...] eezes.html
 
Bref c'est relou, j'espère que ce sera résolu avec Squeeze

Et Xen 4 ?

Ca ne semble pas lié à l'hyperviseur (j'ai testé 3.2 et 3.4, noyau 2.6.26 et 2.6.27 de Suse utilisé par Xenserver), mais clairement au noyal de la Lenny (à priori).
 
Pis le Xen 4 necessite un noyau pv_ops qui m'a l'air bien moisi

 
Tu fais tourner du 32 bits en dom0 64 bits ? C'est quoi comme style de crash ?
 
Effectivement il y  a certains pb avec les domU Lenny sous xenserver on dirait On dirait que le support de debian est un peu laissé de coté Moi qui penser migrer de xenserver 5.0.3 à 5.5, ca me refroidit un peu
 
Edit : pas de template Lenny 64 bits

c'est autant du 32 bits que du 64 qui plante
Le style de crash c'est : machine injoignable par le réseau, console inaccessible, si console déjà ouverte dessus, ne réponds pas, pas de messages d'erreur, et coté dom0 on voit les vCPUs à 100% (donc si 2 vcpus : 200, si 4 : 400, etc.)
A priori ça le fait qu'en cas de plusieurs vcpus.
 
Je vais voir ce que donne le 2.6.32 des backports aux prochains crashs

T'a quoi contre pvops ? 

en dom0 ? bah ça ma l'air bien au point quoi
Je vais attendre que ce soit complètement intégré dans le vanilla (soit disant pour le 2.6.35, moi je dis pas avant le 2.6.40 et je suis optimiste )

 
Je dois bouger une machine qui tourne sous xen comme une horloge depuis des années sans problèmes et ton message m'inquiète. Est-ce que xen est devenu merdique ? Je pensais à la possibilité de passer à virtualbox puisque j'ai d'autres machines qui vont bien aussi (oui je sais VB et xen c'est pas le même usage toussa), mais comme RH va gentiment laisser tomber xen je me dis que c'est peut-être le moment de tout passer sur virtualbox ?

Ben si t'es RedHat, pourquoi choisir virtualbox plutot que KVM

Sinon je dirais pas que Xen est moisi, j'ai quand même plus de 50 VMs, et seulement 3 qui me plantent dans les doigts de façon tout à fait irrégulière et chaotique (elles peuvent tourner niquel pendant des mois, pis planter 2 fois en moins d'une semaine...)

A priori j'accuserai plutot le noyau Lenny, mais il est très difficile de cerner le problème du fait :
- du coté très aléatoire
- de l'absence de message d'erreur du noyau sur la console, ou dans les logs

Bref, affaire à suivre, ce midi je relance mes 3 VMs problématique en 2.6.32, on verra si ça tient

 
Je suis pas 100% RH, je suis plutôt centos .
 
En fait c'est surtout parce que j'en ai bavé des ronds de chapeau avec KVM et les mise en réseau, firewall et consor. J'en suis ressorti vraiment choqué et je n'ai plus retouché à KVM. Mais bon, vu que RH6 par exemple va uniquement supporter KVM, je pense qu'il faudrait que je retente le coup.
 
C'est le pire les pannes aléatoires et l'absence de log. On fini par tout accuser (BIOS, carte mère, noyau, mémoire, alim, voisins...)
Encore pire c'est quand tu tape ton message d'erreur dans google et que t'as que 3 résultats dont 2 en chinois et un lien vers du code de patch brut, tu te sens bien seul.  

Oui le matos j'ai checké aussi, MAJ des BIOS and co.
Mais le problème se produit sur des machines physiques différentes (modèles différents, CPU différents, dates d'achat différentes), donc j'ai ecarté à priori

 
Reste l'ICC  

 
En fait, le seul point commun... c'est toi.

Je suis aussi le point commun avec les 50 et quelques autres qui marchent très bien

Bon, le 2.6.32 32 bits m'a posé un problème de segfault avec exportfs, donc sur un serveur NFS ca le faisait moyen, du coup passage en 2.6.18 pour le polisson
 
Les 2 autres sont passés en 2.6.32

comme ça tu vas avoir plus d'échantillons

comment ça ?
 
J'ai encore 60% de mes VMs en 2.6.18 sans problème constaté
 
En fait c'est Debian que je vais abandonné
 
Je vais passé à VMware + RedHat

Et si tu savais le mix que j'ai dans mes dom0 /o\

Donc c'est des noyal > 2.6.18 qui te posent soucis ?  
 
Dans ce cas, pourquoi ne pas rester en 2.6.18 ?

Parce qu'en général j'utilise le noyau standard de mes distribs, histoire de bénéficier des MAJ de sécurité sans me prendre le chou, et que le 2.6.18 de etch va bientot passer en mode non maintenu

vous auriez un lien concernant le lvm?

oui pour le problème des SPOF pour le dual-fabric.
Mais non, c'est pas a cause du dual fabric que les switches doivent royalement s'ignorer.
En SAN FC par ex, les switches ne doivent surtout pas s'ignorer, et au contraire, dialoguent les un avec les autre en terme de config.
L'intérêt du dual faabric est de séparer également les domaine de configuration, comme ça, en cas de faute humaine, ou de problème l'ors de l'application de la config à une fabric, tu n'impactes pas les paths sur l'autre fabric.
en iSCSI, vu que tu passes sur de l'ethernet, tu n'as pas ce genre de prob vu que tu restes en topo ethernet. Et le bonding est effectivement cité pour augmenter les perfs brutes, mais pas la redondance.
Enfin, pour gérer le bonding, il faut que le switch et l'host utilisent le même algo basé généralement sur un hash des @mac pour savoir quel port utiliser. et forcément, le switch doit avoir la gestion de tous les ports en question -> d'ou limitation a ne faire que du bonding faire un switch (ou config particulière telle stack ou vss) -> d'ou pas conseillé pour redondance.

 
Si tu veux faire des VM simplement et rapidement avec kvm essaye promox ve  

 
merci de m'apprendre mon metier
 
je crois que tu n'as rien compris (ou que tu t'es très mal exprimé), en dual-fabric sur du SAN, il faut justement que les 2 dabric soit totalement indépendantes aussi bien logiquement que physiquement et c'est d'ailleurs ce que n'avait pas compris Cisco en 2001, lors du lancement de leur gammes FC

Différence de la charge entre 2.6.26 et 2.6.32, si c'est pas flagrant que y a une merde, je sais pas ce qu'il vous faut