Reprise du message précédent :

 
Pas pour le moment.    
 

han yong

cela ne change rien, le mariage t'as plu, tu es dès maintenant condamné a plus ou moins court terme, c'est l'histoire de deux ans au grand maximum.

Faut qu'il fasse ça aux Antilles, et qu'il invite tout blabla

Ok, ça vient de là...

Bonsoir, SAV Cisco ?
 
Vos produits c'est dla merde en barre !
 
Merci, au revoir.

en rack

 
J'ai rigolé.

Ca vous dirais d'ouvrir un topic blabla plutôt que de troller ici sur le seul vrai topic Cisco ?

Spotify cébiencatournesurwine.

Oué mais bof, ya jamais ce que je veux. MusicMe s'mieux, et c'est un site

 
Ca fait un peu la bonne excuse.

 
Ouais c'est léger pour le moment, mais j'espere que c'est du à la beta

j'y passe déjà 10 semaines par an, je vais pas en plus m'y marier  

 
Ca sent le gars trop heureux de s'être marié ca

oh, je ne suis pas marié je te rassure

Dernz

Preum's au taff

Et preum's tout court d'ailleurs ^2

Hé ho, spa toi qui décide

Seul au taf, oui

Non, ya des gens dans les locaux

Je sens qu'on va passer une journée en tête-à-tête mon ptit E_e

Ah mais moi je ne bosse pas, pour le moment j'hésite à aller sur la cote ou faire autre chose

 
Comme ca ?

 
Nous on est 2 \o/

2 à preum'ser ? Je crois pas non

El_by est dans le coin j'aurais besoin d'un expert SAN
 

Il est dans son DC là, alors qu'il nous fait croire qu'il est à Rome

bonjour,

petite question à nos experts du SAN venant de quelqu'un issu du monde ethernet : en ethernet pour la redondance on fait des boucles. En FC on monte deux fabrics totalement isolées qu'on connecte jamais ensemble. Dans ce cas si j'ai un accès disque en transit quand le switch de ma fabric 1 pète (la trame FC est perdue sur la crossbar) comment fonctionne la redondance ? Et pourquoi on connecte jamais les deux fabrics ensemble pour jouer sur le routage FSPF ?
 
En gros ça fonctionne comment la redondance en FC ?

 
Mon avis à 2cts :  
 
Si ton I/O met trop de temps à être validé, c'est ton soft de multi pathing qui va prendre le relais et refaire l'I/O sur un path alternatif.
Si jamais tu as une perte de liaison (quand le switch tombe) la aussi c'est detecté par la carte qui le remonte au soft de multi pathing qui reroute l'I/O sur un path alternatif.
 
Quand au fait de ne jamais mélanger les fabrics je penses que c'est un héritage du SCSI (Initiateur - Target). Il serait à mon avis pas terrible d'avoir deux controllers de baie dans une même Fabric. Les I/O risqueraient de se melanger entre les 2 controllers.
 
 

ok donc il y a bien une notion de timeout qui fait que lorsque ça expire on renvoie (comme avec tcp quoi)

en fait je pensais au cas ou il y a une panne sur un élément du switch (crossbar) mais que les interfaces physiques (la linecard) reste up. Mais donc en fait c'est du actif/passif vu du serveur.

je pensais que comme les deux HBAs ont deux WWN différents, quand ça se loggue sur la fabric ça récupère deux FCID différents donc c'est sensé fonctionner non ?  

 
Désolé, je connais pas plus que ça le SAN j'ai une vue admin sys, j'ai des vagues notion et je voudrais pas dire plus de conneries que j'en ai pt etre dis dans mon post précedent

 
je pense que le probléme viens surtout du fait que les fabric sont des éléments actifs du réseau, a savoir que quand tu fais une zone tu la défini sur un seul switch et la zone est diffusé partout et la commutation faite par l'ensemble du systéme.
Donc on peut penser que mélanger les fabric pourrait sérieusement embrouiller le système, car tu multiplie de façon remarquable le nombre de route à chaque nouveau switch que tu rajoute donc le risque est que le temps de transite et la charge des switch FC augmente très fortement car les calculs deviennent extrêmement compliqués.
 
Ça c'est ma théorie à moi, je ne suis sur de rien

Bonjour
 
Nous réfléchissons à prendre l'avion pour partir en vacances. Par conséquent, la saison des crashs commence

                "Et alors ?"

 
C'est plus la période 'disparition d'avion' en ce moment

 
Ils se crashent pas ils disparaissent