[FRnOG] Re : [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo

2011-03-18 Par sujet Thioux nicolas 
De toute façon, si on conjugue le côté 
"écolo-et-c'est-bien-pour-la-planète-et-pour-nous-par-la même-occasion" et 
l'argent que l'on peut économiser et mettre ailleurs, forcément on s'y 
intéresse 
!
C'est la seule façon envisageable pour faire adhérer les entreprises et 
particuliers.


 
 http://router-ecologique.blogspot.com/
L'écologie appliquée aux Réseaux et Télécommunications





De : hadrien 
À : Yohann QUINTON 
Cc : "frnog@frnog.org" 
Envoyé le : Ven 18 mars 2011, 20h 24min 04s
Objet : [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et 
l'écolo pipo

;-) ça me fait rire, mais en même temps, je suis très sérieux

le greenIT (whaou, du marketing ?) à mon sens, c'est réellement de consommer le 
moins de ressources possibles 

(software) pour utiliser le moins de matos possible, et avoir moins de 
factures. 

C'est écolo et économe, bref, c'est logique.

Coté hardware, pareil. ça optimise un max du coté mobile (arm), il est temps 
*de 
faire mieux* coté server & co.

dans la situation actuelle, on peux raisonnablement imaginer que l'énergie 
coutera de plus en plus cher.
l'économiser, c'est "green" et économe. c'est stratégique pour DC !

had


Le 18 mars 2011 à 14:02, Yohann QUINTON a écrit :

> trollons trollons ;-)
> 
> On va vraiment devoir se passer de la sur-couche JAVA qui bouffe des 
> ressources 
>pour masquer l'incompétence de quelques devs ?
> 
> si seulement c'était envisagé je signerai pour le Green-IT tout de suite.
> 
> Le 18/03/11 13:43, hadrien a écrit :
>> 
>> Le 18 mars 2011 à 13:30, Frédéric VANNIÈRE a écrit :
>>> 
>>> Donc, OVH, Ikoula et les autres, si vous voulez vraiment faire  de
>>> l'écologique, proposez de l'hébergement mutualisé qui tienne vraiment
>>> la route et réservez les serveurs dédiés aux clients qui en ont vraiment
>>> besoin.
>>> 
>>> Fred
>> salut Fred,
>> 
>> ce que les marketeux appelle "bidule Cloud tralala" c'est d'une certain 
>> façon 
>>du mutu pour pro ?
>> 
>> Après, sur l'initiative d'OVH (dont je suis aussi client satisfait), c'est 
>> tjs 
>>mieux que rien
>> que d'installer 10MW d'éoliennes, non ? Pareil pour le transport, je prefere 
>> la 
>>péniche
>> au semi !
>> 
>> niveau trollage du dredi, la vrai prochaine étape pour rendre l'utilisation 
>> des 
>>serveurs plus vert,
>> c'est d'abord et avant tout de développer les soft pour qu'ils consomment le 
>>moins possible
>> (moins de ressources, moins de cpu, moins de chaleur, moins d'usure ... ==>  
>>moins d'edf, moins de renouvellement de parc, ... ;)
>> 
>> had---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] DC-DC ATX

2011-03-18 Par sujet Arnaud 

Le 18/03/2011 18:31, David Touitou a écrit :


- Mail original -

Le 18/03/2011 17:29, frede...@perrod.org a écrit :

Arnaud  a écrit :
Peut être en mettant un transfo/alim par baie pour convertir le 220V
en +12V, - 12V, +5V, -5V et 0V et servir directement les composants
de chaque serveur avec les connecteurs normalisés qu'on connait
bien ou un bus d'alim en fond de baie.

Intérêt ?
Tu crois vraiment que tu va consommer moins comme ca? :)

Ca se fait chez des gros (en 12V) :
http://perspectives.mvdirona.com/2011/02/20/DileepBhandarkarOnDatacenterEnergyEfficiency.aspx


C'est bien ce que je dis :)
Syndrome du "Demain, j'fais pareil" sans trop réfléchir :)

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo

2011-03-18 Par sujet hadrien 
;-) ça me fait rire, mais en même temps, je suis très sérieux

le greenIT (whaou, du marketing ?) à mon sens, c'est réellement de consommer le 
moins de ressources possibles 
(software) pour utiliser le moins de matos possible, et avoir moins de 
factures. 
C'est écolo et économe, bref, c'est logique.

Coté hardware, pareil. ça optimise un max du coté mobile (arm), il est temps 
*de faire mieux* coté server & co.

dans la situation actuelle, on peux raisonnablement imaginer que l'énergie 
coutera de plus en plus cher.
l'économiser, c'est "green" et économe. c'est stratégique pour DC !

had


Le 18 mars 2011 à 14:02, Yohann QUINTON a écrit :

> trollons trollons ;-)
> 
> On va vraiment devoir se passer de la sur-couche JAVA qui bouffe des 
> ressources pour masquer l'incompétence de quelques devs ?
> 
> si seulement c'était envisagé je signerai pour le Green-IT tout de suite.
> 
> Le 18/03/11 13:43, hadrien a écrit :
>> 
>> Le 18 mars 2011 à 13:30, Frédéric VANNIÈRE a écrit :
>>> 
>>> Donc, OVH, Ikoula et les autres, si vous voulez vraiment faire  de
>>> l'écologique, proposez de l'hébergement mutualisé qui tienne vraiment
>>> la route et réservez les serveurs dédiés aux clients qui en ont vraiment
>>> besoin.
>>> 
>>> Fred
>> salut Fred,
>> 
>> ce que les marketeux appelle "bidule Cloud tralala" c'est d'une certain 
>> façon du mutu pour pro ?
>> 
>> Après, sur l'initiative d'OVH (dont je suis aussi client satisfait), c'est 
>> tjs mieux que rien
>> que d'installer 10MW d'éoliennes, non ? Pareil pour le transport, je prefere 
>> la péniche
>> au semi !
>> 
>> niveau trollage du dredi, la vrai prochaine étape pour rendre l'utilisation 
>> des serveurs plus vert,
>> c'est d'abord et avant tout de développer les soft pour qu'ils consomment le 
>> moins possible
>> (moins de ressources, moins de cpu, moins de chaleur, moins d'usure ... ==>  
>> moins d'edf, moins de renouvellement de parc, ... ;)
>> 
>> had---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] DC-DC ATX

2011-03-18 Par sujet David Touitou 


- Mail original -
> Le 18/03/2011 17:29, frede...@perrod.org a écrit :
> > Arnaud  a écrit :
> > Peut être en mettant un transfo/alim par baie pour convertir le 220V
> > en +12V, - 12V, +5V, -5V et 0V et servir directement les composants
> > de chaque serveur avec les connecteurs normalisés qu'on connait 
> > bien ou un bus d'alim en fond de baie.
> 
> Intérêt ?
> Tu crois vraiment que tu va consommer moins comme ca? :)

Ca se fait chez des gros (en 12V) : 
http://perspectives.mvdirona.com/2011/02/20/DileepBhandarkarOnDatacenterEnergyEfficiency.aspx

David.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] DC-DC ATX

2011-03-18 Par sujet Raphaël Jacquot 
On Fri, 2011-03-18 at 18:07 +0100, Arnaud wrote:

> Intérêt ?
> Tu crois vraiment que tu va consommer moins comme ca? :)

si c'est pour alimenter un cluster d'alix

http://gallery.sxpert.org/v/reseaux/GrenobleWireless/hardware/20090324239.jpg.html

ca peut etre pratique ;)

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] DC-DC ATX

2011-03-18 Par sujet Arnaud 

Le 18/03/2011 17:29, frede...@perrod.org a écrit :

Arnaud  a écrit :



C'est loin d'être quelque-chose de très répandu; la grande mode en 
ce moment c'est plutôt des alims classiques en 80+ Gold ou Platinum.


D'ailleurs, les boitiers DC ont l'air d'être tous des modèles assez 
anciens (SCSI U-320). Ils ont peut-être été faits sur mesure pour un 
gros client il y a quelques années ?


C'est beau sur le papier, mais comment tu distribues 4kW par baie en 
48VDC?
Ca fait à vue de nez 83Amp à se trimballer par baie, sur une petite 
salle de 100 baies dans les 8300Amp, vu le prix du cuivre en ce 
moment, c'est plutôt une très mauvaise idée :)




Peut être en mettant un transfo/alim par baie pour convertir le 220V 
en +12V, - 12V, +5V, -5V et 0V et servir directement les composants de 
chaque serveur avec les connecteurs normalisés qu'on connait bien ou 
un bus d'alim en fond de baie.


Intérêt ?
Tu crois vraiment que tu va consommer moins comme ca? :)
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] DC-DC ATX

2011-03-18 Par sujet frederic 

Arnaud  a écrit :



C'est loin d'être quelque-chose de très répandu; la grande mode en  
ce moment c'est plutôt des alims classiques en 80+ Gold ou Platinum.


D'ailleurs, les boitiers DC ont l'air d'être tous des modèles assez  
anciens (SCSI U-320). Ils ont peut-être été faits sur mesure pour  
un gros client il y a quelques années ?


C'est beau sur le papier, mais comment tu distribues 4kW par baie en 48VDC?
Ca fait à vue de nez 83Amp à se trimballer par baie, sur une petite  
salle de 100 baies dans les 8300Amp, vu le prix du cuivre en ce  
moment, c'est plutôt une très mauvaise idée :)




Peut être en mettant un transfo/alim par baie pour convertir le 220V  
en +12V, - 12V, +5V, -5V et 0V et servir directement les composants de  
chaque serveur avec les connecteurs normalisés qu'on connait bien ou  
un bus d'alim en fond de baie.


Fred




---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] La convergence voix / données sur un réseau IP unique

2011-03-18 Par sujet Pierre Gaxatte 

Ouais mais alors c'est un bon troll/spam : ils offrent un cocktail ! :)

Le 18/03/2011 16:21, Fabien Delmotte a écrit :

Non c'est un Troll qui sent mauvais :)

Le 18 mars 2011 à 16:20, Fabien Dedenon a écrit :


Le 18/03/2011 15:58, Julie MOISSON-LAJOU a écrit :

AFTER WORK OCEALIS
le jeudi 24 mars 2011
À 18h00
Musée des Arts Décoratifs – Paris I


Spam commercial detected !




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] DC-DC ATX

2011-03-18 Par sujet Laurent GUERBY 
On Fri, 2011-03-18 at 16:33 +0100, Arnaud wrote:
> > C'est loin d'être quelque-chose de très répandu; la grande mode en ce 
> > moment c'est plutôt des alims classiques en 80+ Gold ou Platinum.
> >
> > D'ailleurs, les boitiers DC ont l'air d'être tous des modèles assez 
> > anciens (SCSI U-320). Ils ont peut-être été faits sur mesure pour un 
> > gros client il y a quelques années ?
> 
> C'est beau sur le papier, mais comment tu distribues 4kW par baie en 48VDC?
> Ca fait à vue de nez 83Amp à se trimballer par baie, sur une petite 
> salle de 100 baies dans les 8300Amp, vu le prix du cuivre en ce moment, 
> c'est plutôt une très mauvaise idée :)

D'ou ma precision sur le wattage :), usage pour quelques equipements
"critiques" et peu concentrés.

Laurent



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] DC-DC ATX

2011-03-18 Par sujet MM 
C'est ce qui arrive quand des non spécialistes parlent d'un sujet ;) (moi en 
l'occurrence - qui ai déjà du mal avec mes conversions kva/amp&co)
Une petite visite intéressante chez Google, avec de bon concepts : 
http://www.youtubevideos1.com/google-container-data-center-tour/


Mathieu


Le 18 mars 2011 à 16:33, Arnaud a écrit :

> 
>> C'est loin d'être quelque-chose de très répandu; la grande mode en ce moment 
>> c'est plutôt des alims classiques en 80+ Gold ou Platinum.
>> 
>> D'ailleurs, les boitiers DC ont l'air d'être tous des modèles assez anciens 
>> (SCSI U-320). Ils ont peut-être été faits sur mesure pour un gros client il 
>> y a quelques années ?
> 
> C'est beau sur le papier, mais comment tu distribues 4kW par baie en 48VDC?
> Ca fait à vue de nez 83Amp à se trimballer par baie, sur une petite salle de 
> 100 baies dans les 8300Amp, vu le prix du cuivre en ce moment, c'est plutôt 
> une très mauvaise idée :)
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] DC-DC ATX

2011-03-18 Par sujet Arnaud 


C'est loin d'être quelque-chose de très répandu; la grande mode en ce 
moment c'est plutôt des alims classiques en 80+ Gold ou Platinum.


D'ailleurs, les boitiers DC ont l'air d'être tous des modèles assez 
anciens (SCSI U-320). Ils ont peut-être été faits sur mesure pour un 
gros client il y a quelques années ?


C'est beau sur le papier, mais comment tu distribues 4kW par baie en 48VDC?
Ca fait à vue de nez 83Amp à se trimballer par baie, sur une petite 
salle de 100 baies dans les 8300Amp, vu le prix du cuivre en ce moment, 
c'est plutôt une très mauvaise idée :)


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] La convergence voix / données sur un réseau IP unique

2011-03-18 Par sujet Raphael Maunier - Franceix 
Marketing, marketing :)

Sent from my iPhone

On Mar 18, 2011, at 16:20, Fabien Dedenon  wrote:

> Le 18/03/2011 15:58, Julie MOISSON-LAJOU a écrit :
>> 
>> AFTER WORK OCEALIS
>> le jeudi 24 mars 2011
>> À 18h00
>> Musée des Arts Décoratifs – Paris I  
>> 
> Spam commercial detected !

[FRnOG] Re: [FRnOG] La convergence voix / données sur un réseau IP unique

2011-03-18 Par sujet Fabien Delmotte 
Non c'est un Troll qui sent mauvais :)

Le 18 mars 2011 à 16:20, Fabien Dedenon a écrit :

> Le 18/03/2011 15:58, Julie MOISSON-LAJOU a écrit :
>> 
>> AFTER WORK OCEALIS
>> le jeudi 24 mars 2011
>> À 18h00
>> Musée des Arts Décoratifs – Paris I
>> 
> Spam commercial detected !

Re: [FRnOG] La convergence voix / données sur un réseau IP unique

2011-03-18 Par sujet Fabien Dedenon 

Le 18/03/2011 15:58, Julie MOISSON-LAJOU a écrit :

AFTER WORK OCEALIS
le jeudi 24 mars 2011
À 18h00
Musée des Arts Décoratifs -- Paris I


Spam commercial detected !

[FRnOG] La convergence voix / données sur un réseau IP unique

2011-03-18 Par sujet Julie MOISSON-LAJOU 
AFTER WORK OCEALIS
le jeudi 24 mars 2011
À 18h00
Musée des Arts Décoratifs - Paris I

La convergence voix / données sur un réseau IP unique est à l'origine de 
bénéfices significatifs : réduction des coûts, simplification de gestion, 
amélioration de la productivité, continuité d'activité.
18h00 >> La convergence voix / donnée
Brocade et Shoretel se sont réunis pour fournir une solution fiable, 
transparente et interopérable pour répondre aux besoins des entreprises de 
façon transparente à moindre coût et sans complexification du réseau.
19h00 >> Visite privée du musée
20h30 >> Cocktail


Le GROUPE OCEALIS est partenaire Elite Brocade. Brocade a sélectionné le GROUPE 
OCEALIS pour ses connaissances approfondies, ses compétences et son expertise 
pointue dans les solutions réseaux. Ce partenariat nous permet d'offrir les 
meilleures solutions réseau du marché qui délivrent de véritables avantages aux 
entreprises. Grâce à cela et à la possibilité de profiter des formations, du 
support et des actions marketing Brocade, le GROUPE OCEALIS bénéficie d'une 
proposition très attractive sur le marché.
Les secteurs de la Santé, de l'Education et de l'Industrie nous font confiance 
depuis plus de 15 ans.

Inscription gratuite et obligatoire, réservées au professionnels, au 
04.26.72.91.61 ou par mail à cont...@groupe-ocealis.com
Musée des Arts Décoratifs
« Le Saut du Loup »
107, rue de Rivoli
75001 Paris
Métro : Palais Royal, Pyramides, Tuileries - Bus : 21, 27, 39, 48, 68, 72, 81, 
95 - Parking : Carrousel du Louvre

Re: [FRnOG] DC-DC ATX

2011-03-18 Par sujet François Tigeot 

Bonjour,

Laurent GUERBY wrote:

On Fri, 2011-03-18 at 14:25 +0100, MM wrote:

Je pense que la première chose à faire sur ces grosses infra, c'est
d'avoir des arrivées électriques en courant continu avec les bons
voltages vers les serveurs. 1 alims pour 1 serveurs (si ce
n'est pas 2 avec les alims redondantes) - ça fait une sacré
déperdition.


A part les picoPSU en DC vers ATX j'ai pas trouvé grand chose,
si quelqu'un a des references pour faire une chaine bien
propre EDF / controleur de charge / pack de batterie / DC-DC ATX
je suis preneur. 48V telco mais dans le monde "PC" ATX.


Supermicro a quelques modèles de boitiers avec alims "DC Pwr" qui sont 
censées fonctionner en 48V.


Il faut fouiller dans leur site web; voici quelques liens:

http://www.supermicro.com/products/chassis/1U/811/SC811T-410.cfm
http://www.supermicro.com/products/chassis/1U/812/SC812L-410.cfm
http://www.supermicro.com/products/chassis/1U/812/SC812S-410.cfm
http://www.supermicro.com/products/chassis/1U/813/SC813MT-410C.cfm

C'est loin d'être quelque-chose de très répandu; la grande mode en ce 
moment c'est plutôt des alims classiques en 80+ Gold ou Platinum.


D'ailleurs, les boitiers DC ont l'air d'être tous des modèles assez 
anciens (SCSI U-320). Ils ont peut-être été faits sur mesure pour un 
gros client il y a quelques années ?


--
Francois Tigeot
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Switch en stack ou pas?

2011-03-18 Par sujet Fabien Delmotte 
Pascal,

Tu parles de l'implémentation TRILL de B ou de J ou de XYZ, Il me semble que 
pour un standard les implémentations sont pour le moins incompatible :)

Fabien

Le 18 mars 2011 à 08:25, Pascal Gay a écrit :

> Raphael
> 
> Oui c'est ça basé sur du trill.. Techno jeune mais super prometteuse et 
> innovatrice et déjà dispo chez qui tu sais :) pas de limite de taille ni de 
> bande passante dans une pile ni de problème d'equilibrage de charges entre 
> liens LACP... et produits prêts pour transporter des flux de stockage type 
> FCOE ou ISCSI sur DCB (autres acronymes :)) sans parler de la gestion 
> automatique des mouvements de VM.. Et il y a encore pleins d'autres avantages 
> comme la possibilité d'inserer un service type firewall encryption ou autre 
> load balancing par exemple a chaud dans le cluster sans arrêt du reseau !! 
> Pour moi cette technologie va remplacer le stack dans les années qui viennent 
> (avis personnel) dans les datacenters voire ailleurs
> 
> Pascal Gay
> Mobile +33648755759
> 
> 
> Le 18 mars 2011 à 08:12, "Raphael Maunier"  a écrit 
> :
> 
>> Hello Pascal,
>> 
>> J'ai vu la présentation de Greg, alors si tu parle de Trill vs 802.1aq, je 
>> suis certain que dans pas longtemps cela risque d'être vraiment très 
>> intéressant.
>> 
>> En attendant, le stack reste selon moi la techno la plus "sure" pour le PAG 
>> ( chez certain on aime bien faire des acronymes :) )
>> :)
>> 
>> -- 
>> Raphaël Maunier
>> NEO TELECOMS
>> CTO / Responsable Ingénierie
>> AS8218
>> 
>> 21 rue La Boétie
>> 75008 Paris
>> Tel : +33 1.49.97.07.44
>> Mob : +33 6.86.86.81.76
>> rmaun...@neotelecoms.com 
>> skype : rmaunier
>> 
>> 
>> 
>> On Mar 18, 2011, at 8:03 AM, Pascal Gay wrote:
>> 
>>> Bonjour
>>> 
>>>  il existe de nouvelles solutions pour les serveurs comme des clusters de  
>>> switches ou  fabrique Ethernet... Ni stacks ni châssis..du pay as you grow 
>>> sans les inconvénients du stack et moins cher que les châssis ... 
>>> 
>>> 
>>> Pascal Gay
>>> Mobile +33648755759
>>> 
>>> 
>>> Le 18 mars 2011 à 07:29, "Raphael Maunier"  a 
>>> écrit :
>>> 
 Bonjour,
 
 Stack ou pas Stack ? Tout dépend de l'application et de ce que l'on 
 souhaite faire.
 Que ce soit Chez le constructeur X ou Y, il y aura toujours des avantages 
 ou inconvénients.
 
 Mis à part les bugs qui arrivent sur tous les constructeurs, les limites 
 que nous avons pu voir sur ce système est la coupure (une partie ou 
 l'intégralité)  de trafic lorsque l'on doit mettre à jour le stack avec 
 une release majeure.
 
 Cependant, le day2day, le stack / virtual-chassis permet de vraiment 
 gagner du temps et éviter le "problème" du spanning-tree.
 Le "vrai" stack / virtual-chassis partage la table de routage, les règles 
 par défaut, tout comme un chassis, ce qui facilite le boulot de l'admin et 
 la croissance est plus aisée qu'un châssis. Le pay-as-you-grow est selon 
 moi l'élément de décision, le "problème" de disponibilité est celui qui 
 porte à réfléchir, mais depuis les derniers releases que ce soit chez C ou 
 J, le NSR ( non-stop-forwarding) permet de passer vers une release majeure 
 sans impacter l'intégralité du stack
 
 Me corriger si je me trompe, mais C semble etre plus en avance de 2 ou 3 
 releases que J sur la mise à jour sans coupure.
 
 Le gros chassis c'est bien ( on fait les deux chez Neo donc pas de 
 jaloux), mais pas adapté à tout le monde surtout avec le "Claude" qui est 
 maintenant présent dans toutes les conversations :)
 
 -- 
 Raphaël Maunier
 NEO TELECOMS
 CTO / Responsable Ingénierie
 AS8218
 
 
 
 On Mar 18, 2011, at 4:16 AM, Nicolas MICHEL wrote:
 
> Les stacks en environnement DC je trouve pas ça tip-top. 4500 ou 6500 
> avec les arguments qui vont bien (non on parle pas du prix ;) )
> 
> Un client m'a remonté un problème sur un 3750 stack-pas-tres-Wise et j'ai 
> testé ça en lab: 
> 
> Sur le master tu configure ip vrf forwarding X , tu sauvegardes la 
> config, tu perds le courant sur ton master. Le slave passe Master et le 
> Master passe slave a son retour. 
> 
> Maintenant tu fais un show run et tu t’aperçois que t'as perdu la 
> commande qui attribue une VRF a ton port . fun isnt it ?
> 
> Pour ceux qui veulent tester et jeter un oeil : CSCtn46230
> 
> Une nouvelle version devrait corriger le bug assez rapidement.
> 
> 
> 
> Le 18 mars 2011 00:21, Thery  a écrit :
> Sans aucune hesitation, deux n5k en tete en 10g les n2k en dessous, il 
> existe meme des bundles cisco 2x n5k 20 port  plus 6x n2k pour 4€ 
> remisé. Dans les bundles tu as meme 40 FET inclus pour tes interco, As tu 
> besoin des ref de ces bundles ? Il y en 3-4 differents. Salut 
> 
> Envoyé de mon iPhone
> 
> Le 17 mars 2011 à 23:33, Rachid Zitouni  a

[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo

2011-03-18 Par sujet Jean-Dominique BAYLAC 

Le 18/03/2011 14:25, MM a écrit :

Bonjour,

Je pense que la première chose à faire sur ces grosses infra, c'est d'avoir des 
arrivées électriques en courant continu avec les bons voltages vers les 
serveurs.
1 alims pour 1 serveurs (si ce n'est pas 2 avec les alims 
redondantes) - ça fait une sacré déperdition.
Ce genre de chose est tout à fait envisageable vu l'échelle d'OVH par exemple 
(ils ont déjà du matériel custom, pourquoi ne pas pousser plus loin ?)
De mémoire, OVH a ce genre de pratique, avec d'autres techniques, pour diminuer 
les consos dans leurs DC.

Je salue en tout cas les efforts de ces deux entreprises (OVH étant précurseur, 
notamment au niveau du refroidissement).
Mieux vaut de petits gestes, même si il y a du marketing derrière, que rien du 
tout comme beaucoup le font.
Sachant que tout ceci coûte en prime moins de sous, pourquoi s'en priver ?


Mathieu
   


Et en plus, le marketing c'est tellement du vent que ça refroidit 
indirectement les serveurs.
Pour un système de clim efficace, mettez tout ce qui brasse de l'air 
devant et tout ceux qui nous les pompe derrière.

--
Jean-Dominique

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Switch en stack ou pas?

2011-03-18 Par sujet Fabien Delmotte 
Bonjour,

Il est possible de faire du double attachement de serveur sur deux TOR 
distincts, la technologie type MLAG le permet.
Il est possible de faire du PVLAN distribué sur plusieurs équipements chez 
certains constructeurs.

Par contre utiliser le parallèle entre token ring et le fonctionnement d'un 
stack n'est pas généralisable à toute les techno de stacking.

Fabien


Le 18 mars 2011 à 13:16, Raymond Caracatamatere a écrit :

> Ouais Sympa !! tout ça, merci à tous pour vos réponses (en privée et en 
> public), Steven je veux bien ton script python :)
> On est d'accord que le stack est super pratique mais les mises à jour sont 
> trop dangereuses, et les coupures de service ne seront pas admises.
> Je suis surpris que si peu de monde apprécie le stack, cela évite beaucoup de 
> brassage vis à vis des gros chassis.
> Après peut-être que les cluster de switch (idée de Pascal) peuvent aussi être 
> une solution, mais cela me semble un peu jeune, et je préfère travailler sur 
> des choses éprouvées ("du qui marche" plutôt que "du qui va marcher")
> Après il me reste ma problématique de pvlan, sans les stack, c'est pénible.
> 
> Et sans parler de stack donc plutôt top-of-the-rack ou plutôt gros chassis + 
> brassage ? moi j'étais plus parti sur du top-of-the-rack, vous savez si les 
> constructeurs propose du pvlan (ou similaire) au travers de plusieurs switchs 
> non stackés? vous avez un retour d'expérience sur ce genre d'archi ?
> 
> Merci beaucoup pour votre aide.
> 
> Ray
> 
> 
> Le 18 mars 2011 09:59, Steven Le Roux  a écrit :
> J'aurais tendance à te dire que la tolérence doit être applicative et capable 
> d'être répartie et distribuée. Les techno d'ajourd'hui le permettent 
> largement, mais je ne sais pas ce que tu comptes faire tourner derriere.
> 
> Chez moi on a effectivement systématiquement des stack pour chaque baie, pour 
> nos 4 dc et env 40 baies dans chaque. Sachant qu'on brasse l'impair d'un 
> membre et le pair de l'autre et que chaque port non brassé est recopié 
> automatiquement (j'ai un script python qui s'en occupe si ça t'intéresse). 
> 
> D'expérience, en plus de 10 ans, on n'a jamais eu besoin du stack, même si 
> c'est en prévision (c'est arrivé une fois mais sur un stack dédié user), le 
> fait est qu'aujourd'hui les techno qu'on tend à utiliser saurait très bien se 
> débrouiller si un switch tombait. Même pour automatiser la montée en charge.
> 
> Tout dépend donc de ton budget...  après en cas de pépin, le remplacement est 
> assez transparent car la conf reste en provisioning.
> 
> En résumé : 
> Si tu as des applis un peu moderne, investi plutôt en RAM :) sinon casse la 
> tirelire 
> 
> La réflexion pour le double attachement est un peu la même. Maintenant en 
> terme de perf, il faut savoir qu'un stack c'est un anneau (type token ring), 
> donc tu as des latences assez élevé plus tu rajoutes de membre) et tu divises 
> ta capacité par le nombre de membre dans le stack. Si pour la plupart des 
> applis c'est transparent, pour des applis temps réel critique ça peut avoir 
> une incidence.
> 
> 
> 2011/3/17 Raymond Caracatamatere 
> Bonjour à tous,
> 
> Je dois réfléchir à une architecture réseau "très haute-disponibilité", et je 
> me pose des questions sur ce qu'il est mieux de faire au niveau des switchs.
> Il est indispensable de double attacher les serveurs pour la redondance 
> (utilisation aussi de bladecenter DELL M1000e), et j'aimerai avoir vos avis 
> sur les stack de switch.
> Avec 2x5 baies, je peux faire 2 stacks de 5 switchs par rangé de baie.
> 
> Les stacks c'est sexy car l'administration est sympa et simplifiée, et 
> surtout on peut utiliser le Pvlan (ou similaire) j'en suis fan et le LACP, 
> par contre les mises à jour de firmware c'est triste quand il faut couper 
> tout le stack ... ou bien quand tout ton stack à un soucis.
> D'après vos expériences, plutôt le stack ou plutôt les switchs seuls ?
> 
> Et le double attachement des serveurs plutôt en spanning-tree (cela me semble 
> très très moche) ou plutôt en teaming ?
> Il existe une solution miracle?
> 
> Si vous avez des idées pour faire balancer mon cœur :)
> 
> Merci beaucoup
> 
> Ray
> 
> 
> 
> 
> 
> 
> 
> -- 
> Steven Le Roux
> Jabber-ID : ste...@jabber.fr
> 0x39494CCB 
> 2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB
>

Re: [FRnOG] DC-DC ATX (was: Trolldi : OVH, Ikoula et l'écolo pipo)

2011-03-18 Par sujet Laurent GUERBY 
On Fri, 2011-03-18 at 14:25 +0100, MM wrote:
> Je pense que la première chose à faire sur ces grosses infra, c'est
> d'avoir des arrivées électriques en courant continu avec les bons
> voltages vers les serveurs. 1 alims pour 1 serveurs (si ce
> n'est pas 2 avec les alims redondantes) - ça fait une sacré
> déperdition.

Bonjour,

A part les picoPSU en DC vers ATX j'ai pas trouvé grand chose,
si quelqu'un a des references pour faire une chaine bien
propre EDF / controleur de charge / pack de batterie / DC-DC ATX
je suis preneur. 48V telco mais dans le monde "PC" ATX.

Je précise que je parle de quelques kW maximum, pas en MW :).

Merci a tous,

Laurent



---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] RE: [FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo

2011-03-18 Par sujet Clément Thery 
Bonjour a tous,

J'ai récemment déployé des infra Nexus/serveur blade Cisco chez un hébergeur
internet, ce client possédait 40 Baies, avec les consos énergétiques qui
vont bien, aujourd'hui, sont infra tient sur 3 baies, il a diminué sa
facture électrique par 4, ce qui lui paie sa plate forme complète sur 18
mois (en comptant les économies de location de baies chez sont hébergeurs)
Green IT pourquoi pas, mais surtout IT haute densité et mutualisé ! 

THERY


   

-Message d'origine-
De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de MM
Envoyé : vendredi 18 mars 2011 14:26
À : hadrien
Cc : frnog@frnog.org
Objet : [FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo
pipo

Bonjour,

Je pense que la première chose à faire sur ces grosses infra, c'est d'avoir
des arrivées électriques en courant continu avec les bons voltages vers les
serveurs.
1 alims pour 1 serveurs (si ce n'est pas 2 avec les alims
redondantes) - ça fait une sacré déperdition.
Ce genre de chose est tout à fait envisageable vu l'échelle d'OVH par
exemple (ils ont déjà du matériel custom, pourquoi ne pas pousser plus loin
?)
De mémoire, OVH a ce genre de pratique, avec d'autres techniques, pour
diminuer les consos dans leurs DC.

Je salue en tout cas les efforts de ces deux entreprises (OVH étant
précurseur, notamment au niveau du refroidissement).
Mieux vaut de petits gestes, même si il y a du marketing derrière, que rien
du tout comme beaucoup le font.
Sachant que tout ceci coûte en prime moins de sous, pourquoi s'en priver ?


Mathieu

Le 18 mars 2011 à 13:43, hadrien a écrit :

> niveau trollage du dredi, la vrai prochaine étape pour rendre
l'utilisation des serveurs plus vert,
> c'est d'abord et avant tout de développer les soft pour qu'ils consomment
le moins possible
> (moins de ressources, moins de cpu, moins de chaleur, moins d'usure ...
==> moins d'edf, moins de renouvellement de parc, ... ;)

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo

2011-03-18 Par sujet Dominique Rousseau 
Le Fri, Mar 18, 2011 at 01:43:31PM +0100, hadrien [hadr...@cap270.com] a écrit:
> 
> ce que les marketeux appelle "bidule Cloud tralala" c'est d'une
> certain façon du mutu pour pro ?

C'est généralement juste de la plateforme de virtualisation avec tout le
bastringue qui va bien pour faire du provisioning automatisé, et tout.
(et c'est après tout une forme de mutualisation)

En plateforme mutualisée très cloud, et qui se résume pas à ce que je
décris, c'est l'AppEngine de Google et les trucs qui y ressemblent
vraiment.



-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
50, rue Riolan 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo

2011-03-18 Par sujet MM 
Bonjour,

Je pense que la première chose à faire sur ces grosses infra, c'est d'avoir des 
arrivées électriques en courant continu avec les bons voltages vers les 
serveurs.
1 alims pour 1 serveurs (si ce n'est pas 2 avec les alims 
redondantes) - ça fait une sacré déperdition.
Ce genre de chose est tout à fait envisageable vu l'échelle d'OVH par exemple 
(ils ont déjà du matériel custom, pourquoi ne pas pousser plus loin ?)
De mémoire, OVH a ce genre de pratique, avec d'autres techniques, pour diminuer 
les consos dans leurs DC.

Je salue en tout cas les efforts de ces deux entreprises (OVH étant précurseur, 
notamment au niveau du refroidissement).
Mieux vaut de petits gestes, même si il y a du marketing derrière, que rien du 
tout comme beaucoup le font.
Sachant que tout ceci coûte en prime moins de sous, pourquoi s'en priver ?


Mathieu

Le 18 mars 2011 à 13:43, hadrien a écrit :

> niveau trollage du dredi, la vrai prochaine étape pour rendre l'utilisation 
> des serveurs plus vert,
> c'est d'abord et avant tout de développer les soft pour qu'ils consomment le 
> moins possible
> (moins de ressources, moins de cpu, moins de chaleur, moins d'usure ... ==> 
> moins d'edf, moins de renouvellement de parc, ... ;)

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l 'écolo pipo

2011-03-18 Par sujet Raphaël Jacquot 
On Fri, 2011-03-18 at 14:17 +0100, Damien Wetzel wrote:
> Sans voiloir lancer un troll, je me suis
> toujours demandé si on pouvait aller jusqu'à
> l'OS, peux t'on dire que linux est plus green
> que windows parcequ'il consomme moins de watts ?
> Damien,

tout dépends des niveaux de documentation des chipsets...
si ton chipset est documenté correctement, y'a des chances pour que ce
soit vrai ;)

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l 'écolo pipo

2011-03-18 Par sujet Damien Wetzel 
Sans voiloir lancer un troll, je me suis
toujours demandé si on pouvait aller jusqu'à
l'OS, peux t'on dire que linux est plus green
que windows parcequ'il consomme moins de watts ?
Damien,

hadrien writes:
 > 
 > 
 > Le 18 mars 2011 à 13:30, Frédéric VANNIÈRE a écrit :
 > > 
 > > 
 > > Donc, OVH, Ikoula et les autres, si vous voulez vraiment faire  de
 > > l'écologique, proposez de l'hébergement mutualisé qui tienne vraiment
 > > la route et réservez les serveurs dédiés aux clients qui en ont vraiment
 > > besoin.
 > > 
 > > Fred
 > 
 > salut Fred,
 > 
 > ce que les marketeux appelle "bidule Cloud tralala" c'est d'une certain 
 > façon du mutu pour pro ?
 > 
 > Après, sur l'initiative d'OVH (dont je suis aussi client satisfait), c'est 
 > tjs mieux que rien 
 > que d'installer 10MW d'éoliennes, non ? Pareil pour le transport, je prefere 
 > la péniche
 > au semi !
 > 
 > niveau trollage du dredi, la vrai prochaine étape pour rendre l'utilisation 
 > des serveurs plus vert,
 > c'est d'abord et avant tout de développer les soft pour qu'ils consomment le 
 > moins possible
 > (moins de ressources, moins de cpu, moins de chaleur, moins d'usure ... ==> 
 > moins d'edf, moins de renouvellement de parc, ... ;)
 > 
 > had---
 > Liste de diffusion du FRnOG
 > http://www.frnog.org/
 > 
 > 

-- 
~~
 Damien WETZEL (ATANAR TECHNOLOGIES)("`-/")_.-'"``-._
 http://www.atanar.com  . . `; -._)-;-,_`)
   (v_,)'  _  )`-.\  ``-'
 Phone:+33 6 62 29 61 77   _.- _..-_/ / ((.'
 - So much to do, so little time -   ((,.-'   ((,/
~
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo

2011-03-18 Par sujet Yohann QUINTON 

trollons trollons ;-)

On va vraiment devoir se passer de la sur-couche JAVA qui bouffe des 
ressources pour masquer l'incompétence de quelques devs ?


si seulement c'était envisagé je signerai pour le Green-IT tout de suite.

Le 18/03/11 13:43, hadrien a écrit :


Le 18 mars 2011 à 13:30, Frédéric VANNIÈRE a écrit :


Donc, OVH, Ikoula et les autres, si vous voulez vraiment faire  de
l'écologique, proposez de l'hébergement mutualisé qui tienne vraiment
la route et réservez les serveurs dédiés aux clients qui en ont vraiment
besoin.

Fred

salut Fred,

ce que les marketeux appelle "bidule Cloud tralala" c'est d'une certain façon 
du mutu pour pro ?

Après, sur l'initiative d'OVH (dont je suis aussi client satisfait), c'est tjs 
mieux que rien
que d'installer 10MW d'éoliennes, non ? Pareil pour le transport, je prefere la 
péniche
au semi !

niveau trollage du dredi, la vrai prochaine étape pour rendre l'utilisation des 
serveurs plus vert,
c'est d'abord et avant tout de développer les soft pour qu'ils consomment le 
moins possible
(moins de ressources, moins de cpu, moins de chaleur, moins d'usure ... ==>  
moins d'edf, moins de renouvellement de parc, ... ;)

had---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo

2011-03-18 Par sujet hadrien 


Le 18 mars 2011 à 13:30, Frédéric VANNIÈRE a écrit :
> 
> 
> Donc, OVH, Ikoula et les autres, si vous voulez vraiment faire  de
> l'écologique, proposez de l'hébergement mutualisé qui tienne vraiment
> la route et réservez les serveurs dédiés aux clients qui en ont vraiment
> besoin.
> 
> Fred

salut Fred,

ce que les marketeux appelle "bidule Cloud tralala" c'est d'une certain façon 
du mutu pour pro ?

Après, sur l'initiative d'OVH (dont je suis aussi client satisfait), c'est tjs 
mieux que rien 
que d'installer 10MW d'éoliennes, non ? Pareil pour le transport, je prefere la 
péniche
au semi !

niveau trollage du dredi, la vrai prochaine étape pour rendre l'utilisation des 
serveurs plus vert,
c'est d'abord et avant tout de développer les soft pour qu'ils consomment le 
moins possible
(moins de ressources, moins de cpu, moins de chaleur, moins d'usure ... ==> 
moins d'edf, moins de renouvellement de parc, ... ;)

had---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo

2011-03-18 Par sujet Frédéric VANNIÈRE 

Bonjour,

C'est la journée "green" avec Ikoula qui nous sort ses serveurs
Greenfish XL et surtout OVH qui lance un communiqué de presse
pour parler d'éoliennes et de transport de serveurs par péniches.

OVH :
http://www.romandie.com/infos/news2/110316121337.ci7c43ru.asp

Ikoula :
http://www.ikoula.com/portals/0/images/newsletter/mars11_express/index.html


Je ne me permet pas de juger pas de la qualité des prestations mais
seulement la communication (je suis client OVH et j'apprécie beaucoup
Ikoula).

Dans les deux cas on nous parle de serveurs dédiés écolo-vert-green
alors qu'un serveur dédié est intrinsèquement non écologique. C'est
pareil pour les voitures, une voiture électrique ne sera jamais
écologique.

Ces deux hébergeurs, comme beaucoup d'autres, proposent des machines
dédiés qui consomment peu à des tarifs très intéressants. Sauf que,
qui a besoin d'un serveur dédié ?!  normalement pas grand monde.

L'hébergement réellement écologique c'est le mutualisé, sur les
architectures actuelles on peut faire tenir des gros sites.
Malheureusement pour les clients ces hébergements sont souvent très
limités (connexions mysql, envoi de mails, performances, espace disque
 ...) et pour un peu plus cher ils peuvent avoir leur dédié à eux
tout seul. Pour l'hébergeur un dédié fait plus de chiffre d'affaire
et c'est pourquoi il va pousser ses clients mutualisés un peu trop
consommateurs vers un dédié.

Donc, OVH, Ikoula et les autres, si vous voulez vraiment faire  de
l'écologique, proposez de l'hébergement mutualisé qui tienne vraiment
la route et réservez les serveurs dédiés aux clients qui en ont vraiment
besoin.

Fred.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Switch en stack ou pas?

2011-03-18 Par sujet Raymond Caracatamatere 
Ouais Sympa !! tout ça, merci à tous pour vos réponses (en privée et en
public), Steven je veux bien ton script python :)
On est d'accord que le stack est super pratique mais les mises à jour sont
trop dangereuses, et les coupures de service ne seront pas admises.
Je suis surpris que si peu de monde apprécie le stack, cela évite beaucoup
de brassage vis à vis des gros chassis.
Après peut-être que les cluster de switch (idée de Pascal) peuvent aussi
être une solution, mais cela me semble un peu jeune, et je préfère
travailler sur des choses éprouvées ("du qui marche" plutôt que "du qui va
marcher")
Après il me reste ma problématique de pvlan, sans les stack, c'est pénible.

Et sans parler de stack donc plutôt top-of-the-rack ou plutôt gros chassis +
brassage ? moi j'étais plus parti sur du top-of-the-rack, vous savez si les
constructeurs propose du pvlan (ou similaire) au travers de plusieurs
switchs non stackés? vous avez un retour d'expérience sur ce genre d'archi ?

Merci beaucoup pour votre aide.

Ray


Le 18 mars 2011 09:59, Steven Le Roux  a écrit :

> J'aurais tendance à te dire que la tolérence doit être applicative et
> capable d'être répartie et distribuée. Les techno d'ajourd'hui le permettent
> largement, mais je ne sais pas ce que tu comptes faire tourner derriere.
>
> Chez moi on a effectivement systématiquement des stack pour chaque baie,
> pour nos 4 dc et env 40 baies dans chaque. Sachant qu'on brasse l'impair
> d'un membre et le pair de l'autre et que chaque port non brassé est recopié
> automatiquement (j'ai un script python qui s'en occupe si ça t'intéresse).
>
> D'expérience, en plus de 10 ans, on n'a jamais eu besoin du stack, même si
> c'est en prévision (c'est arrivé une fois mais sur un stack dédié user), le
> fait est qu'aujourd'hui les techno qu'on tend à utiliser saurait très bien
> se débrouiller si un switch tombait. Même pour automatiser la montée en
> charge.
>
> Tout dépend donc de ton budget...  après en cas de pépin, le remplacement
> est assez transparent car la conf reste en provisioning.
>
> En résumé :
> Si tu as des applis un peu moderne, investi plutôt en RAM :) sinon casse la
> tirelire
>
> La réflexion pour le double attachement est un peu la même. Maintenant en
> terme de perf, il faut savoir qu'un stack c'est un anneau (type token ring),
> donc tu as des latences assez élevé plus tu rajoutes de membre) et tu
> divises ta capacité par le nombre de membre dans le stack. Si pour la
> plupart des applis c'est transparent, pour des applis temps réel critique ça
> peut avoir une incidence.
>
>
> 2011/3/17 Raymond Caracatamatere 
>
>> Bonjour à tous,
>>
>> Je dois réfléchir à une architecture réseau "très haute-disponibilité", et
>> je me pose des questions sur ce qu'il est mieux de faire au niveau des
>> switchs.
>> Il est indispensable de double attacher les serveurs pour la redondance
>> (utilisation aussi de bladecenter DELL M1000e), et j'aimerai avoir vos avis
>> sur les stack de switch.
>> Avec 2x5 baies, je peux faire 2 stacks de 5 switchs par rangé de baie.
>>
>> Les stacks c'est sexy car l'administration est sympa et simplifiée, et
>> surtout on peut utiliser le Pvlan (ou similaire) j'en suis fan et le LACP,
>> par contre les mises à jour de firmware c'est triste quand il faut couper
>> tout le stack ... ou bien quand tout ton stack à un soucis.
>> D'après vos expériences, plutôt le stack ou plutôt les switchs seuls ?
>>
>> Et le double attachement des serveurs plutôt en spanning-tree (cela me
>> semble très très moche) ou plutôt en teaming ?
>> Il existe une solution miracle?
>>
>> Si vous avez des idées pour faire balancer mon cœur :)
>>
>> Merci beaucoup
>>
>> Ray
>>
>>
>>
>>
>>
>
>
> --
> Steven Le Roux
> Jabber-ID : ste...@jabber.fr
> 0x39494CCB 
> 2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB
>

[FRnOG] Operateurs en Afrique ?.

2011-03-18 Par sujet Philippe Marrot 
Bonjour,

Je recherche des opérateurs capable de livrer de l'IP entre Paris et les
principales
villes du Gabon/Congo/Cameroun (pas de satellite).

Merci de vos infos.
Cordialement.
PM.

Re: [FRnOG] Switch en stack ou pas?

2011-03-18 Par sujet Steven Le Roux 
J'aurais tendance à te dire que la tolérence doit être applicative et
capable d'être répartie et distribuée. Les techno d'ajourd'hui le permettent
largement, mais je ne sais pas ce que tu comptes faire tourner derriere.

Chez moi on a effectivement systématiquement des stack pour chaque baie,
pour nos 4 dc et env 40 baies dans chaque. Sachant qu'on brasse l'impair
d'un membre et le pair de l'autre et que chaque port non brassé est recopié
automatiquement (j'ai un script python qui s'en occupe si ça t'intéresse).

D'expérience, en plus de 10 ans, on n'a jamais eu besoin du stack, même si
c'est en prévision (c'est arrivé une fois mais sur un stack dédié user), le
fait est qu'aujourd'hui les techno qu'on tend à utiliser saurait très bien
se débrouiller si un switch tombait. Même pour automatiser la montée en
charge.

Tout dépend donc de ton budget...  après en cas de pépin, le remplacement
est assez transparent car la conf reste en provisioning.

En résumé :
Si tu as des applis un peu moderne, investi plutôt en RAM :) sinon casse la
tirelire

La réflexion pour le double attachement est un peu la même. Maintenant en
terme de perf, il faut savoir qu'un stack c'est un anneau (type token ring),
donc tu as des latences assez élevé plus tu rajoutes de membre) et tu
divises ta capacité par le nombre de membre dans le stack. Si pour la
plupart des applis c'est transparent, pour des applis temps réel critique ça
peut avoir une incidence.


2011/3/17 Raymond Caracatamatere 

> Bonjour à tous,
>
> Je dois réfléchir à une architecture réseau "très haute-disponibilité", et
> je me pose des questions sur ce qu'il est mieux de faire au niveau des
> switchs.
> Il est indispensable de double attacher les serveurs pour la redondance
> (utilisation aussi de bladecenter DELL M1000e), et j'aimerai avoir vos avis
> sur les stack de switch.
> Avec 2x5 baies, je peux faire 2 stacks de 5 switchs par rangé de baie.
>
> Les stacks c'est sexy car l'administration est sympa et simplifiée, et
> surtout on peut utiliser le Pvlan (ou similaire) j'en suis fan et le LACP,
> par contre les mises à jour de firmware c'est triste quand il faut couper
> tout le stack ... ou bien quand tout ton stack à un soucis.
> D'après vos expériences, plutôt le stack ou plutôt les switchs seuls ?
>
> Et le double attachement des serveurs plutôt en spanning-tree (cela me
> semble très très moche) ou plutôt en teaming ?
> Il existe une solution miracle?
>
> Si vous avez des idées pour faire balancer mon cœur :)
>
> Merci beaucoup
>
> Ray
>
>
>
>
>


-- 
Steven Le Roux
Jabber-ID : ste...@jabber.fr
0x39494CCB 
2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB

[FRnOG] Offre d'emploi

2011-03-18 Par sujet Florent Menot 
Bonjour à tous et à toutes. Premier poste pour moi sur la liste. 

Désolé d'avance si cela ne correspond pas à la charte (mais bon, après tout, on 
est trolldi).

Voilà, l'entreprise où je travaille recherche un architecte réseau et il nous 
est possible de coopter.
Je vous copie-colle l'annonce (pas de commentaires dessus svp, elle n'est pas 
de 
moi mais des RH). 
Si vous êtes intéressés ou si vous voulez plus de précisions, n'hésitez pas à 
demander. 

Cordialement, 

Florent Menot, 
Développeur Logiciel IsaPaye
Isagri

L'annonce : 

Architecte Réseau

Pour son équipe Infrastructure Réseaux Clients, composée de 12 personnes, 
l'entreprise recherche 1 Architecte Réseaux (H/F)


Vos missions :


Au sein de l'équipe Infrastructure Réseaux Clients, vous aurez en charge les 
études d’avant-projet, la conception d’architectures réseau et la gestion de 
projets d’intégration. 


Vous aurez notamment les missions suivantes :
Collecte et analyse des besoins clients (audit de l’existant, propositions 
d’évolutions) 

Conduite des études d’avant-projet (solutions techniques, business case…) 
Définition des architectures réseau et des configurations associées en fonction 
des besoins exprimés 

Rédaction des livrables associés et conduite de présentations (équipe, 
management…)

Votre profil : 
Diplôme de niveau Bac+5 ou équivalent 
Bonnes capacités rédactionnelles et de formalisation

Expérience minimale de 3 ans dans le domaine du réseau

Vous avez un goût prononcé pour les réseaux, vous souhaitez mettre à profit 
votre expérience et vos compétences dans des environnements challengeants tout 
en continuant à évoluer dans votre expertise, 

Vous êtes autonome, mobile, avez de bonnes capacités rédactionnelles, souhaitez 
rejoindre un environnement dynamique et formateur, n'hésitez pas à nous 
contacter. 


Conditions proposées :

CDI basé à Beauvais, à pourvoir dès que possible.
Rémunération selon expérience (fixe + prime + intéressement + participation).

Re: [FRnOG] Switch en stack ou pas?

2011-03-18 Par sujet Pascal Gay 
Bonjour

 il existe de nouvelles solutions pour les serveurs comme des clusters de  
switches ou  fabrique Ethernet... Ni stacks ni châssis..du pay as you grow sans 
les inconvénients du stack et moins cher que les châssis ...


Pascal Gay
Mobile +33648755759


Le 18 mars 2011 à 07:29, "Raphael Maunier" 
mailto:rmaun...@neotelecoms.com>> a écrit :

Bonjour,

Stack ou pas Stack ? Tout dépend de l'application et de ce que l'on souhaite 
faire.
Que ce soit Chez le constructeur X ou Y, il y aura toujours des avantages ou 
inconvénients.

Mis à part les bugs qui arrivent sur tous les constructeurs, les limites que 
nous avons pu voir sur ce système est la coupure (une partie ou l'intégralité)  
de trafic lorsque l'on doit mettre à jour le stack avec une release majeure.

Cependant, le day2day, le stack / virtual-chassis permet de vraiment gagner du 
temps et éviter le "problème" du spanning-tree.
Le "vrai" stack / virtual-chassis partage la table de routage, les règles par 
défaut, tout comme un chassis, ce qui facilite le boulot de l'admin et la 
croissance est plus aisée qu'un châssis. Le pay-as-you-grow est selon moi 
l'élément de décision, le "problème" de disponibilité est celui qui porte à 
réfléchir, mais depuis les derniers releases que ce soit chez C ou J, le NSR ( 
non-stop-forwarding) permet de passer vers une release majeure sans impacter 
l'intégralité du stack

Me corriger si je me trompe, mais C semble etre plus en avance de 2 ou 3 
releases que J sur la mise à jour sans coupure.

Le gros chassis c'est bien ( on fait les deux chez Neo donc pas de jaloux), 
mais pas adapté à tout le monde surtout avec le "Claude" qui est maintenant 
présent dans toutes les conversations :)

--
Raphaël Maunier
NEO TELECOMS
CTO / Responsable Ingénierie
AS8218



On Mar 18, 2011, at 4:16 AM, Nicolas MICHEL wrote:

Les stacks en environnement DC je trouve pas ça tip-top. 4500 ou 6500 avec les 
arguments qui vont bien (non on parle pas du prix ;) )

Un client m'a remonté un problème sur un 3750 stack-pas-tres-Wise et j'ai testé 
ça en lab:

Sur le master tu configure ip vrf forwarding X , tu sauvegardes la config, 
tu perds le courant sur ton master. Le slave passe Master et le Master passe 
slave a son retour.

Maintenant tu fais un show run et tu t’aperçois que t'as perdu la commande qui 
attribue une VRF a ton port . fun isnt it ?

Pour ceux qui veulent tester et jeter un oeil : CSCtn46230

Une nouvelle version devrait corriger le bug assez rapidement.



Le 18 mars 2011 00:21, Thery 
<clement.th...@aciernet.com>
 a écrit :
Sans aucune hesitation, deux n5k en tete en 10g les n2k en dessous, il existe 
meme des bundles cisco 2x n5k 20 port  plus 6x n2k pour 4€ remisé. Dans les 
bundles tu as meme 40 FET inclus pour tes interco, As tu besoin des ref de ces 
bundles ? Il y en 3-4 differents. Salut

Envoyé de mon iPhone

Le 17 mars 2011 à 23:33, Rachid Zitouni 
<rachid.zito...@gmail.com>
 a écrit :

Hello,
Assez d'accord sur la solution virtuel châssis. Chez cisco il y a la gamme 
nexus 5k avec les modules nexus 2 k qui offre une bonne densité de ports et une 
couverture assez large pour les besoins de connectivité serveurs avec un 
upgrade a chaud possible ( issu) Pour simplifier ta distribution cuivre tu peux 
partir sur une distrib cuivre en top of rack et y placer tes nexus 2k. Pour la 
scalabilite, c'est 500 vlan en mst et 250 en pvst, 480 ports serveurs en lacp 
dans une certaine configuration sinon ce sera du teaming. Cote prix : bien 
remplit (480 ports) un virtuel châssis redonde coûte moins cher que 2 stack de 
la gamme 3750g  et maintenant 3750x. Cote management les deux solutions se 
valent sauf pour la supervision et le monitoring (XML vs snmp). Autre point : 
issu est en roadmap je crois sur la gamme 3750x a vérifier ...

A+
Rachid

Le 17 mars 2011 à 22:04, "Fregate84" 
<fregat...@free.fr>
 a écrit :

Les virtuals chassis c’est pas mal. 2 gros switch indépendant mais vu comme un 
seul. Comme ca pas de spanning tree, tout en LACP …. Et une bonne redondance. 
Bon par contre ca coute un peu plus chère que des swich en stack …


De :   
owner-fr...@frnog.org 
[mailto:owner-fr...@frnog.org]
 De la part de Raymond Caracatamatere
Envoyé : jeudi 17 mars 2011 21:54
À :    
frnog@frnog.org
Objet : [FRnOG] Switch en stack ou pas?

Bonjour à tous,

Je dois réfléchir à une architecture réseau "très haute-disponibilité", et je 
me pose des questions sur ce qu'il est mieux de faire au niveau des switchs.
Il est indispensable d

Re: [FRnOG] Switch en stack ou pas?

2011-03-18 Par sujet Pascal Gay 
Raphael

Oui c'est ça basé sur du trill.. Techno jeune mais super prometteuse et 
innovatrice et déjà dispo chez qui tu sais :) pas de limite de taille ni de 
bande passante dans une pile ni de problème d'equilibrage de charges entre 
liens LACP... et produits prêts pour transporter des flux de stockage type FCOE 
ou ISCSI sur DCB (autres acronymes :)) sans parler de la gestion automatique 
des mouvements de VM.. Et il y a encore pleins d'autres avantages comme la 
possibilité d'inserer un service type firewall encryption ou autre load 
balancing par exemple a chaud dans le cluster sans arrêt du reseau !! Pour moi 
cette technologie va remplacer le stack dans les années qui viennent (avis 
personnel) dans les datacenters voire ailleurs

Pascal Gay
Mobile +33648755759


Le 18 mars 2011 à 08:12, "Raphael Maunier" 
mailto:rmaun...@neotelecoms.com>> a écrit :

Hello Pascal,

J'ai vu la présentation de Greg, alors si tu parle de Trill vs 802.1aq, je suis 
certain que dans pas longtemps cela risque d'être vraiment très intéressant.

En attendant, le stack reste selon moi la techno la plus "sure" pour le PAG ( 
chez certain on aime bien faire des acronymes :) )
:)

--
Raphaël Maunier
NEO TELECOMS
CTO / Responsable Ingénierie
AS8218

21 rue La Boétie
75008 Paris
Tel : +33 1.49.97.07.44
Mob : +33 6.86.86.81.76
rmaun...@neotelecoms.com
skype : rmaunier



On Mar 18, 2011, at 8:03 AM, Pascal Gay wrote:

Bonjour

 il existe de nouvelles solutions pour les serveurs comme des clusters de  
switches ou  fabrique Ethernet... Ni stacks ni châssis..du pay as you grow sans 
les inconvénients du stack et moins cher que les châssis ...


Pascal Gay
Mobile +33648755759


Le 18 mars 2011 à 07:29, "Raphael Maunier" 
<rmaun...@neotelecoms.com>
 a écrit :

Bonjour,

Stack ou pas Stack ? Tout dépend de l'application et de ce que l'on souhaite 
faire.
Que ce soit Chez le constructeur X ou Y, il y aura toujours des avantages ou 
inconvénients.

Mis à part les bugs qui arrivent sur tous les constructeurs, les limites que 
nous avons pu voir sur ce système est la coupure (une partie ou l'intégralité)  
de trafic lorsque l'on doit mettre à jour le stack avec une release majeure.

Cependant, le day2day, le stack / virtual-chassis permet de vraiment gagner du 
temps et éviter le "problème" du spanning-tree.
Le "vrai" stack / virtual-chassis partage la table de routage, les règles par 
défaut, tout comme un chassis, ce qui facilite le boulot de l'admin et la 
croissance est plus aisée qu'un châssis. Le pay-as-you-grow est selon moi 
l'élément de décision, le "problème" de disponibilité est celui qui porte à 
réfléchir, mais depuis les derniers releases que ce soit chez C ou J, le NSR ( 
non-stop-forwarding) permet de passer vers une release majeure sans impacter 
l'intégralité du stack

Me corriger si je me trompe, mais C semble etre plus en avance de 2 ou 3 
releases que J sur la mise à jour sans coupure.

Le gros chassis c'est bien ( on fait les deux chez Neo donc pas de jaloux), 
mais pas adapté à tout le monde surtout avec le "Claude" qui est maintenant 
présent dans toutes les conversations :)

--
Raphaël Maunier
NEO TELECOMS
CTO / Responsable Ingénierie
AS8218



On Mar 18, 2011, at 4:16 AM, Nicolas MICHEL wrote:

Les stacks en environnement DC je trouve pas ça tip-top. 4500 ou 6500 avec les 
arguments qui vont bien (non on parle pas du prix ;) )

Un client m'a remonté un problème sur un 3750 stack-pas-tres-Wise et j'ai testé 
ça en lab:

Sur le master tu configure ip vrf forwarding X , tu sauvegardes la config, 
tu perds le courant sur ton master. Le slave passe Master et le Master passe 
slave a son retour.

Maintenant tu fais un show run et tu t’aperçois que t'as perdu la commande qui 
attribue une VRF a ton port . fun isnt it ?

Pour ceux qui veulent tester et jeter un oeil : CSCtn46230

Une nouvelle version devrait corriger le bug assez rapidement.



Le 18 mars 2011 00:21, Thery 
<clement.th...@aciernet.com>
 a écrit :
Sans aucune hesitation, deux n5k en tete en 10g les n2k en dessous, il existe 
meme des bundles cisco 2x n5k 20 port  plus 6x n2k pour 4€ remisé. Dans les 
bundles tu as meme 40 FET inclus pour tes interco, As tu besoin des ref de ces 
bundles ? Il y en 3-4 differents. Salut

Envoyé de mon iPhone

Le 17 mars 2011 à 23:33, Rachid Zitouni 
<rachid.zito...@gmail.com>
 a écrit :

Hello,
Assez d'accord sur la solution virtuel châssis. Chez cisco il y a la gamme 
nexus 5k avec les modules nexus 2 k qui offre une bonne densité de ports et une 
couverture assez large pour les besoins de connectivité serveurs avec un 
upgrade a chaud possible ( issu) Pour simplifier ta distribution

Re: [FRnOG] Switch en stack ou pas?

2011-03-18 Par sujet Raphael Maunier 
Hello Pascal,

J'ai vu la présentation de Greg, alors si tu parle de Trill vs 802.1aq, je suis 
certain que dans pas longtemps cela risque d'être vraiment très intéressant.

En attendant, le stack reste selon moi la techno la plus "sure" pour le PAG ( 
chez certain on aime bien faire des acronymes :) )
:)

-- 
Raphaël Maunier
NEO TELECOMS
CTO / Responsable Ingénierie
AS8218

21 rue La Boétie
75008 Paris
Tel : +33 1.49.97.07.44
Mob : +33 6.86.86.81.76
rmaun...@neotelecoms.com 
skype : rmaunier



On Mar 18, 2011, at 8:03 AM, Pascal Gay wrote:

> Bonjour
> 
>  il existe de nouvelles solutions pour les serveurs comme des clusters de  
> switches ou  fabrique Ethernet... Ni stacks ni châssis..du pay as you grow 
> sans les inconvénients du stack et moins cher que les châssis ... 
> 
> 
> Pascal Gay
> Mobile +33648755759
> 
> 
> Le 18 mars 2011 à 07:29, "Raphael Maunier"  a écrit 
> :
> 
>> Bonjour,
>> 
>> Stack ou pas Stack ? Tout dépend de l'application et de ce que l'on souhaite 
>> faire.
>> Que ce soit Chez le constructeur X ou Y, il y aura toujours des avantages ou 
>> inconvénients.
>> 
>> Mis à part les bugs qui arrivent sur tous les constructeurs, les limites que 
>> nous avons pu voir sur ce système est la coupure (une partie ou 
>> l'intégralité)  de trafic lorsque l'on doit mettre à jour le stack avec une 
>> release majeure.
>> 
>> Cependant, le day2day, le stack / virtual-chassis permet de vraiment gagner 
>> du temps et éviter le "problème" du spanning-tree.
>> Le "vrai" stack / virtual-chassis partage la table de routage, les règles 
>> par défaut, tout comme un chassis, ce qui facilite le boulot de l'admin et 
>> la croissance est plus aisée qu'un châssis. Le pay-as-you-grow est selon moi 
>> l'élément de décision, le "problème" de disponibilité est celui qui porte à 
>> réfléchir, mais depuis les derniers releases que ce soit chez C ou J, le NSR 
>> ( non-stop-forwarding) permet de passer vers une release majeure sans 
>> impacter l'intégralité du stack
>> 
>> Me corriger si je me trompe, mais C semble etre plus en avance de 2 ou 3 
>> releases que J sur la mise à jour sans coupure.
>> 
>> Le gros chassis c'est bien ( on fait les deux chez Neo donc pas de jaloux), 
>> mais pas adapté à tout le monde surtout avec le "Claude" qui est maintenant 
>> présent dans toutes les conversations :)
>> 
>> -- 
>> Raphaël Maunier
>> NEO TELECOMS
>> CTO / Responsable Ingénierie
>> AS8218
>> 
>> 
>> 
>> On Mar 18, 2011, at 4:16 AM, Nicolas MICHEL wrote:
>> 
>>> Les stacks en environnement DC je trouve pas ça tip-top. 4500 ou 6500 avec 
>>> les arguments qui vont bien (non on parle pas du prix ;) )
>>> 
>>> Un client m'a remonté un problème sur un 3750 stack-pas-tres-Wise et j'ai 
>>> testé ça en lab: 
>>> 
>>> Sur le master tu configure ip vrf forwarding X , tu sauvegardes la 
>>> config, tu perds le courant sur ton master. Le slave passe Master et le 
>>> Master passe slave a son retour. 
>>> 
>>> Maintenant tu fais un show run et tu t’aperçois que t'as perdu la commande 
>>> qui attribue une VRF a ton port . fun isnt it ?
>>> 
>>> Pour ceux qui veulent tester et jeter un oeil : CSCtn46230
>>> 
>>> Une nouvelle version devrait corriger le bug assez rapidement.
>>> 
>>> 
>>> 
>>> Le 18 mars 2011 00:21, Thery  a écrit :
>>> Sans aucune hesitation, deux n5k en tete en 10g les n2k en dessous, il 
>>> existe meme des bundles cisco 2x n5k 20 port  plus 6x n2k pour 4€ 
>>> remisé. Dans les bundles tu as meme 40 FET inclus pour tes interco, As tu 
>>> besoin des ref de ces bundles ? Il y en 3-4 differents. Salut 
>>> 
>>> Envoyé de mon iPhone
>>> 
>>> Le 17 mars 2011 à 23:33, Rachid Zitouni  a écrit :
>>> 
 Hello,
 Assez d'accord sur la solution virtuel châssis. Chez cisco il y a la gamme 
 nexus 5k avec les modules nexus 2 k qui offre une bonne densité de ports 
 et une couverture assez large pour les besoins de connectivité serveurs 
 avec un upgrade a chaud possible ( issu) Pour simplifier ta distribution 
 cuivre tu peux partir sur une distrib cuivre en top of rack et y placer 
 tes nexus 2k. Pour la scalabilite, c'est 500 vlan en mst et 250 en pvst, 
 480 ports serveurs en lacp dans une certaine configuration sinon ce sera 
 du teaming. Cote prix : bien remplit (480 ports) un virtuel châssis 
 redonde coûte moins cher que 2 stack de la gamme 3750g  et maintenant 
 3750x. Cote management les deux solutions se valent sauf pour la 
 supervision et le monitoring (XML vs snmp). Autre point : issu est en 
 roadmap je crois sur la gamme 3750x a vérifier ...
 
 A+
 Rachid 
 
 Le 17 mars 2011 à 22:04, "Fregate84"  a écrit :
 
> Les virtuals chassis c’est pas mal. 2 gros switch indépendant mais vu 
> comme un seul. Comme ca pas de spanning tree, tout en LACP …. Et une 
> bonne redondance. Bon par contre ca coute un peu plus chère que des swich 
> en stack …
> 
>  
> De : owner-fr...@frnog.org [mailto:owner-