Re: [FRnOG] [TECH] Buzz autour du SD-WAN

[Jérémy RIZZOLI]

Cible directe : service provider
> Cible indirecte (les clients du service provider) : retail étendu
> (grosse distrib, grosse distrib de carburant, etc.), multinationales
> avec des agences à l'étranger (ex : boites de com' / pub', gros cabinets
> d'avocats Paris / NY, agences de presse)
> 
> Deux choses que tu fais en SD-WAN que tu peux faire en classique mais en
> investissant du temps et des devs :
> - aggregation de liens sur critère layer 7 (mptcp + DPI pour classifier
> et envoyer le trafic dans tel ou tel tunnel)
> - créer des VPN facilement, avec des points de terminaisons qui peuvent
> être dans des clouds publics tiers (= s'affranchir des offres de type
> cloud connect qui sont vendues un bras, et ne pas avoir à monter un
> IPSEC à la main sur une VM Junisco ou PfSense).
> 
> Donc gain pour le SP : offrir des accès en redondance actif-actif +
> critères, et étendre son offre VPN en dehors de son backbone MPLS, sans
> les couts de "je fais du DMVPN qui finit dans une VRF, et j'y crois à
> mort, ça va marcher"
> 
> C'est pas révolutionnaire du tout, c'est un package de technos déjà
> existantes depuis des années.
> Chez Cisco c'est l'aboutissement d'une stratégie qui a démarré avec PFR
> il y a presque 10 ans, c'est dire.
> 
> Après à l'usage, à part le MPTCP qui a un usage concret démontré (cf :
> OTB OVH), le reste est un enrobage bullshitomarketing pour ne pas avoir
> à monter son Ansible soit même.
> Mais ça a l'avantage de fonctionner, contrairement à vouloir réintégrer
> ça soit même dans une Debian + Quagga + DPDK (faisable, ceci dit, mais
> au combien casse gueule). 
> 
> Le 14 août 2017 à 11:29, Richard Klein <varicap@gmail.com
> <mailto:varicap@gmail.com>> a écrit :
> 
> Voir :
> 
> http://www.zdnet.fr/actualites/sd-lan-et-sd-wan-deux-approches-differentes-
> pour-le-software-defined-networking-39841794.htm
> 
> <http://www.zdnet.fr/actualites/sd-lan-et-sd-wan-deux-approches-differentes-
> pour-le-software-defined-networking-39841794.htm>
> 
> Ou plus proche des clients GP la Livebox décentralisé. ..
> 
> C est assurément une bonne idée mais mon principe à moi c est de
> garder mes
> données chez moi et de rester indépendant ( a 99%) d'une infra que je ne
> maîtrise pas.
> 
> Question il se passe quoi quand votre chaîne à le maillont faible
> qui est
> cassé ?
> 
> Et sur la sécurité les experts en pensent quoi ? Le jour où il y a une
> faille tous tombe ?
> Principe de base d'un grand penseur de l'internet : tous ce qui
> passe sur
> internet est susceptible d'être publique
> 
> Richard
> 
> Le 14 août 2017 11:08, "David Ponzone" <david.ponz...@gmail.com
> <mailto:david.ponz...@gmail.com>> a écrit :
> 
> C'est rigolo, pour moi, le SD-WAN c'était l'inverse: plus d'intelligence
> dans le CPE pour s'affranchir de la dépendance à un carrier.
> 
> David Ponzone
> 
> 
> 
> > Le 14 août 2017 à 17:01, Solarus <sola...@ultrawaves.fr
> <mailto:sola...@ultrawaves.fr>> a écrit :
> >
> > Le 2017-08-14 09:48, Jérémy RIZZOLI a écrit :
> >
> >> Néanmoins, j'ai quand même du mal à voir à qui s'adresse en terme de
> >> cible, ce type de technos.
> >
> > Salut Jérémy.
> >
> > Le principal intérêt que je vois au SD-WAN c’est de pouvoir
> envoyer chez
> les clients des boitiers moins «intelligents» et donc moins chers,
> l’intelligence étant gérée en cœur de réseau.
> > L’avantage c’est que le boitier n’a plus qu’à gérer le lien physique
> (ADSL, SDSL, FO), la couche IP étant gérée au niveau du backbone, ce qui
> limite le risque d’erreur de conf sur les routeurs distants.
> > Les configurations sont récupérées depuis le cœur de réseau, ce qui
> facilite les déploiements.
> >
> > L’autre avantage c’est qu’on centralise l’intelligence réseau et la
> puissance nécessaire sur les contrôleurs SDN et les PE, ce qui
> facilite les
> upgrades puisqu’il y a moins de matériel à changer chez les clients.
> > Sinon oui, le principe c’est équivalent à celui de puppet ou
> ansible, il
> s’agit de tout «masteriser» à distance à partir d’un contrôleur.
> >
> > De toute façon c’est le modèle poussé par Juniper et Cisco qui se
> font la
> guerre sur ce secteur donc on risque d’y passer bon gré,mal gré.
> >
> > Cordialement.
> > Solarus.
> >
> >
> > ---
> > 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/
> 
> 
> 
> 
> -- 
> Cordialement,
> 
> Guillaume BARROT


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

[FRnOG] [TECH] Buzz autour du SD-WAN

[Jérémy RIZZOLI]

Bonjour à tous,

Depuis un petit moment déjà j'essaye de suivre toutes les évolutions
récentes qui changent un peu de façon radicale la façon de concevoir
notre taff d'ingé réseau, et notamment les évolutions récentes autour du
SD-WAN et toutes les technos afférentes.

J'avoue que j'ai un peu de mal à y voir clair dans tout ce Buzz
marketing autour du SD-WAN et ses technos, qui ne sont pour moi, que des
technos de réseau overlay à grand renforts de tunnels over Internet dans
95% des cas.

Du coup, je m'adresse à la mailing list pour receuillir vos avis,
subjectifs ou objectifs, et des docs de techos sur le sujet, loin du
blabla marketing associé.

Ma perception actuelle du SD-WAN c'est que c'est poussé pour favoriser
des fournisseurs de cloud publics, tels que AWS et leur amis, à
concentrer la quasi totalité des réseaux d'entreprise (et leur traffic)
à travers le monde, avec un risque non négligeable de voir apparaitre de
plus en plus un conglomérat à la "Oracle bis" avec Amazon et les GAFA de
façon générale.

Pour moi, c'est n'est ni plus, ni moins que l'automatisation de
tunneling à la volée le tout mis dans un joli Control Plane associé avec
une belle interface Web qui déchire avec des graphes qui en jette et la
promesse o combien absurde que tout est "auto-géré" et qu'on pourra
alors se passer de l'OPEX qui coûte cher ..

Néanmoins, j'ai quand même du mal à voir à qui s'adresse en terme de
cible, ce type de technos.

En effet, je vois mal comment un opérateur réseau, qui se doit de
maitriser ses points d'entrée/sortie ainsi que ses tuyaux par définition
et la Bande passante/latence associée (surtout en 2017) peut vouloir
jongler avec des technos type SD-WAN, vu que tout ou presque passe alors
over Internet, sur un réseau dont on ne contrôle donc, ni la latence, ni
le routage, à contrario de son propre réseau IP/MPLS classique.
Et pourtant, il semblerait que bon nombre d'opérateurs vont dans cette
direction de façon [presque] aveugle, alors du coup je me pose aussi la
question, histoire de pas mourir con:

Comment font-il pour garder cette maitrise des points entrée/sortie et
du Core quand on fait confiance à 100% à un/des fournisseur(s) tier(s)
qui imposent leur règles (cf AWS) et à l'Internet (qui lui même repose
sur des infrastructures plus traditionnelles de façon immuable pour
certaines parties ..)

N'empile t-on pas les couches de façon grotesque au final, au risque
d'en perdre totalement la maitrise ? (l'abstraction totale du lien
physique me choque) Est-ce que ces technos, finalement, ne contribuent
pas au renforcement de la concentration du traffic chez les GAFA et donc
au détriment de la neutralité du net ?

Si vous avez des éclairages à m'apporter, je suis preneur, mais j'ai un
peu peur de lancer le troll 2017 .. essayez de rester un poil objectif :)


Jérémy


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

Re: [FRnOG] [TECH] HP Dual 8GB microSD EM USB kit

[Jérémy RIZZOLI]

Chez nous, on déploie les Hyperviseurs de façon automatique avec
PXE/AutoDeploy et le profil d'hôte qui va bien, puis on reboote en
forçant une install satefull sur un dongle USB local 8G (Clées USB
Carrefour) (ou carte double SD quand il y en a), tout en gardant la conf
dans le PXE/AutoDeploy. Ca permet d'assurer le coup si la clée USB fail,
et inversement, et ça juste marche très bien moyennant quelques mises à
jour de profil d'hôte régulièrement.

Ensuite on colle 1 SSD (120/256Go) en SATA/SAS direct dans chaque
Hyperviseur, sans contrôleur RAID, on fait au plus simple, genre 1,5fois
la taille de la RAM, juste histoire de l'utiliser pour du Flash Read
Cache sur certaines VM ReadIntensive et d'y mettre aussi le swap des VM
en cas de surcharge .. pour éviter de plomber le SAN inutilement avec
des IOPS lors des incidents/surcharges.
Quant aux logs, un NFS sur un petit NAS dans ce but est amplement
suffisant, et ça coute pas cher .. et ça préserve le SAN pour des IOPS
de prod réelle ..

Au final des machines de recup suffisent, pas besoin de cartes double SD
ou de controleur RAID/disques, juste un petit SSD sur LDLC suffit, les
machines sont moins complexes, moins couteuses, et plus fiables car
moins de composants donc moins de firmwares buggés (notamment les
controleurs RAID)

Enfin pour ceux qui se demandent ce qui se passe quand le SSD pète (1
seule fois en 5 ans), bah ma réponse est : rien, juste que le swap
utilisé et la charge prise par le FRC se reporteront sur le SAN .. mais
acceptable, et ça continue de tourner le temps de remplacer après mise
en maintenance de l'Hyperviseur.

My 2 Cents

Jérémy

Le 19/06/2017 à 14:04, Duchet Rémy a écrit :
> On met les LOGS sur un volume (SAN). Vmware le gère très bien, et on peut 
> même mettre plusieurs ESXI sur le même volume.
> (https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.install.doc_50%2FGUID-9F67DB52-F469-451F-B6C8-DAE8D95976E7.html
>  ) 
> Après, comme on est sur des M6xx, faut sortir la lame pour changer la/les 
> cartes. De toute façon, vaut mieux éviter les unplug sous tension.
> 
> -Message d'origine-
> De : David Ponzone [mailto:david.ponz...@gmail.com]
> Envoyé : lundi, 19 juin 2017 13:59
> À : Duchet Rémy 
> Cc : Arnaud Launay ; frnog@frnog.org
> Objet : Re: [FRnOG] [TECH] HP Dual 8GB microSD EM USB kit
> 
> 
> 
>> Le 19 juin 2017 à 13:28, Duchet Rémy  a écrit :
>>
>> Par ici on est plutôt adepte de la SD en dual (RAID1 directement intégré sur 
>> la carte mère) des PowerEdge.
>> Pas une seule SD de HS sur les 6 dernières années, sur une centaine de 
>> serveurs.
>> Économie à l'achat, + la conso électrique.
>> C'est sûr que le cout de remplacement (humain) est important, mais c'est le 
>> même entre les cartes et les disques.
> 
> Tu as la version avec les 2 slots visibles à l’arrière (donc remplacement 
> facile) ?
> C’est vrai qu’ils ont été plus malins que HP sur ce coup-là.
> 
>> Dans ce genre de config l'ESX boot plus lentement, et faut oublier les R/W 
>> sur les cartes de façon trop répété.
> 
> C’est un point intéressant ça.
> On fait quoi des logs quand on boot sur de la flash ?
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 


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

Re: [FRnOG] [BIZ] Contacts pour Societé de Maintenance en datacenters

[Jérémy RIZZOLI]

Précision importante par rapport à cette annonce sur laquelle nombre
d'entre vous m'ont déjà répondu et je vous en remercie

Ce sera dans le cadre d'un appel d'offre, donc pour le moment c'est une
prise de contacts, ne vous étonnez pas si on ne répond pas tout de suite,
on se donne 1 semaine pour collecter, 1 semaine pour vous recontacter et 1
semaine pour lancer l'appel d'offre.
Les processus internes ça peu prendre du temps ...

Autres précisions importantes, on privilégiera une societé capable
d'intervenir sur les 3 pays: France (Paris), Allemagne (Frankfurt) et Suède
idéalement (mais pour celui-ci on se fait pas trop d'illusions quand même)
car notre intéret c'est de gérer le stock sur les 3 surtout ..
Les équipements vont du système pur (serveurs) aux équipement telco legacy
parfois complexes en passant par du Réseau pur (switchs/routeurs), là aussi
on privilégiera le savoir-faire et l'expérience forcément .. et les équipes
qui ont déjà tout dans leurs valises (Fibres / câbles série / PC avec
connection 4G, matos de spare demandé,  etc etc)

En attendant merci pour l'efficacité de certains sur cette Mailling-list,
les contacts [BiZ] c'est tout de même impressionant de réactivité ..

Jérémy


Le 7 avril 2017 à 09:39, Jérémy RIZZOLI <jeremy.rizz...@gmail.com> a écrit :

> Bonjour à tous,
>
> Nous sommes actuellement à la recherche d'une societé prestataire pour
> faire la maintenance physique complète de nos équipements en Datacenter, en
> France et en Allemagne notamment.
>
> Il s'agirait entre autres de:
>
>
>- Racker / Dé-racker des machines  et/ou équipements réseaux
>- Savoir configurer un iDRAC/ILO/ilom/IPMI avec un minimum
>d'instructions
>- Câblage et etiquettage propre avec référentiel et respect de
>consignes imposées.
>- Remplacement de cartes et/ou composants hardware dans des machines
>ou équipements (Disques durs, RAM, switchs, controlleurs)
>- Debug physique basique: savoir se connecter sur une console série
>sur les équipements avec un PC/adaptateur et idéalement possibilité
>d'intervention remote pour nous en cas de gros pépins.
>- Gestion complète d'un stock de pièce de spare, stockage inclu
>idéalement.
>
> Bref, être nos yeux et nos mains sur site.
> Le tout en autonomie totale dans nos emplacements de DC en France,
> Allemagne et Suède , avec si possible une Garantie de temps d'intervention
> <4h.
>
>
> Si vous avez des contacts de societé à même de gérer cela et avec une
> certaine réputation/professionalisme, je suis preneur.
>
> Merci
>
> Bien cordialement
>
> Jérémy Rizzoli
>
>

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

[FRnOG] [BIZ] Contacts pour Societé de Maintenance en datacenters

[Jérémy RIZZOLI]

Bonjour à tous,

Nous sommes actuellement à la recherche d'une societé prestataire pour
faire la maintenance physique complète de nos équipements en Datacenter, en
France et en Allemagne notamment.

Il s'agirait entre autres de:


   - Racker / Dé-racker des machines  et/ou équipements réseaux
   - Savoir configurer un iDRAC/ILO/ilom/IPMI avec un minimum d'instructions
   - Câblage et etiquettage propre avec référentiel et respect de consignes
   imposées.
   - Remplacement de cartes et/ou composants hardware dans des machines ou
   équipements (Disques durs, RAM, switchs, controlleurs)
   - Debug physique basique: savoir se connecter sur une console série sur
   les équipements avec un PC/adaptateur et idéalement possibilité
   d'intervention remote pour nous en cas de gros pépins.
   - Gestion complète d'un stock de pièce de spare, stockage inclu
   idéalement.

Bref, être nos yeux et nos mains sur site.
Le tout en autonomie totale dans nos emplacements de DC en France,
Allemagne et Suède , avec si possible une Garantie de temps d'intervention
<4h.


Si vous avez des contacts de societé à même de gérer cela et avec une
certaine réputation/professionalisme, je suis preneur.

Merci

Bien cordialement

Jérémy Rizzoli

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

Re: [FRnOG] [TECH] CPE 4G

[Jérémy RIZZOLI]

Huawei E5186 et ses variantes trouvable sur eBay desimlocké. 300€ et
c'est du très très bon matos, c'est juste pas rackable mais ça fait du
vrai MIMO sur 2 ports externes SMA et c'est LTE cat 6 compliant (oui
oui): 70M en rase campagne avec 2 antennes bien pointées.
Cerise sur le gateau, c'est compatible VoLTE même si pas encore exploité
par la plupart des opérateurs :)
L'inconvénient, c'est que l'interface web/ de gestion est assez
verrouillée, mais rien d'insurmontable.

Sinon toute la gamme Airlink chez Sierra .. mais LTE cat 4 only, là pour
le coup ils sont "rackable" plus ou moins. A voir selon ton besoin. La
plupart des Airlink proposent 2 ports SMA compatibles MIMO aussi ..
(même si Sierra appelle ça RX diversity mais bon ..)
Attention sur AirLink, faut le firmware EU qui va bien pour gérer les
bandes LTE en Europe.

PS: oubliez les dongles USB pour de la 4G "serieuse".

Le 17/11/2016 à 15:51, David Ponzone a écrit :
> Jamais rien trouvé de sérieux dans un budget de 150-200€.
> 
> Tu peux aller voir chez Sierra Wireless ou Cradlepoint, mais c’est pas du 
> 19in.
> 
> Ou sinon, tu fabriques ça toi-même avec un Mikrotik, et une clé USB 4G qui 
> aurait un connecteur d’antenne (2, ça va être plus délicat…).
> Chez Huawei, je vois des USB 4G qui prennent une antenne externe  (je 
> comprends pas trop où on la connecté sur la clé d’ailleurs).
> 
>> Le 17 nov. 2016 à 15:31, flor...@siegenthaler.mx a écrit :
>>
>> Bonjour la liste,
>>
>> Pour un projet FAI associatif pour connecter une manifestation je recherche 
>> un CPE 4G avec deux sorties pour antennes extérieure directionnelles (MIMO) 
>> et si possible rackable.
>>
>> On a pas un grand budget donc pas Cisco, j'ai déjà regardé du côté de 
>> Drayteck, TP-Link, ça pourrait aller mais si vous avez des conseils plus 
>> avisés ou du matériel plus performant je suis preneur.
>>
>> Merci d'avance!
>> Bon après-midi
>> -- 
>> Florian Siegenthaler
>> ---
>> 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/

[FRnOG] [JOBS] Ingénieur Systèmes et Réseaux et Ingénieur Télécom réseaux Mobiles

[Jérémy RIZZOLI]

Bonjour la liste,

Notre societé Mobiquithings, désormais membre du groupe Sierra Wireless
recrute !
Nous sommes une petite société toute jeune de 15 personnes environ,
basée sur Sophia Antipolis dans le domaine des opérateurs mobile M2M.
Nous proposons une solution de SIM intelligente et une connectivité
réseau associée, qui font désormais partie intégrante du portfolio
SierraWireless:

https://www.sierrawireless.com/products-and-solutions/sims-connectivity-and-cloud-services/iot-sim/

Nous cherchons à monter une équipe d'architecture/Ingénierie réseau
complète, sachant que nous partons de quasiment rien, nous sommes
aujourd'hui 2 personnes pour s'occuper du réseau et du système et nous
souhaitons agrandir cette équipe à 6 personnes à minima, chacune avec
des domaines de compétences, idéalement par binômes.

Notre équipe aura en charge la définition de l'architecture de notre
cœur de réseau mobile, ainsi que sa mise en place technique et assurera
un support niveau 3 aux équipes de support client.

Les compétences recherchées sont les suivantes:

Coté réseau IP:

Coeur de réseau IP/MPLS.
IPv6 avec expérience opérateur souhaitée.
Carrier Grade NAT et assimilés.
Masterisation du BGP et connaissance approfondie des BCP souhaitée.
Forte orientation SDN/NFV si possible.

Coté Système:

Connaissances VMware, KVM et Amazon
Connaissances administration Linux et/ou FreeBSD
Masterisation du DNS au sens large.
Connaissances ZenOSS et/ou autre systèmes de supervision (on est ouverts)
Connaissances outils de gestion et déploiement: Puppet/SVN/Git/rancid
etc etc...
Connaissances Postfix ou équivalents souhaitées
Connaissances approfondies sur le bas niveau Android souhaitées,
éventuellement profil dev bas niveau Android.

Coté Telco:

Connaissances Sigtran/SS7, GRX/IPX, et signalisation LTE.
Connaissances des produits HLR et de façon générale tous les composants
d'un coeur de réseau mobile 2G/3G/4G
Connaissances SCTP
Connaissances VoIP au sens large

Côté humain:

Capacité à bosser en autonomie complète et à faire des fouilles
archéologiques si nécessaire en cherchant les infos par soi-même.
Capacité à reverse-engineerer rapidement un réseau sans aucune doc et à
faire la doc en conséquence, car cela fera malheureusement partie du
quotidien.
Capacité à communiquer énormément en ligne et en permanence:
Skype/IRC/Whatever. La majorité des décisions et réunions seront en
ligne, l'équipe étant majoritairement en télétravail.
RIGUEUR comme maître mot de toute action.
Capacité à tenir la pression en cas de pépins et à produire rapidement
et proprement quand c'est nécessaire.


Le poste est basé soit à Sophia-Antipolis, soit à Paris, soit en
télétravail partout en France, on est nous mêmes en télétravail à temps
plein.
Déplacements à prévoir régulièrement dans nos DCs en France et à
l'étranger, il faut aimer trainer dans les DC car on risque d'y passer
un peu de temps dans les mois qui viennent..
La rémunération sera fonction des compétences et de leur maitrise. On ne
cherche pas l'homme/femme à tout faire, mais plutôt des gens très
pointus, dans chacun des 3 gros domaines, et principalement sur la
partie réseau IP. Bien entendu on est sur des postes à rémunération
équivalente d'un poste basé en Région Parisienne pour ces compétences.
Je précise qu'il n'y a pas d'astreintes officielle pour le moment mais
ça peut venir par la suite en complément selon le besoin.

N'hésitez pas à m'envoyer vos CV, on étudiera toutes les propositions
sans exception.


Jérémy


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

Re: [FRnOG] [TECH] Pdu managé double source ?

[Jérémy RIZZOLI]

Hello,

Pour avoir mis en place de l'ATS dit bas de gamme de marque Digipower, je
considère qu'effectivement ça reste des équipements qui posent quelques
contraintes strictes à respecter qui sont:

1) Avoir 2 arrivées totalement indépendantes et distinctes, avec un
déphasage minime entre les deux, idéalement une sortie ondulée et une
sortie normale, mais ça implique d'avoir quand même un très bon onduleur
(avec un bon coeff phi). On constate souvent que des onduleurs un peu vieux
avec un coeff phi de l'ordre de 0,90 commencent à poser pb, en dessous de
0,9, faut oublier.

2) Ne mettre que ce qui est mono alimenté au cul de d'ATS et que ce qui est
strictement nécessaire. Mettre des machines double alimenté n'a aucun
intérêt de toute façon, puisque ces machines ont déjà un mécanisme de
bascule interne, souvent assez lissé avec des condo donc bien plus efficace
qu'un ATS.

3) Limiter la charge derrière un ATS au strict minimum (genre les switchs
uniquement et les équipements faible charge mono alim). Les appels de
courant lors des bascules peuvent parfois poser problème avec les
disjoncteurs si ceux-ci ne sont pas prévus pour cela, même si c'est
généralement prévu en datacenter, faut pas le perdre de vue.

4) Faire attention aux équipement mono alim derrière l'ATS qui crament
silencieusement et qui déphasent le courant de telle sorte que le coeff
phi passe aux environs de 0,8: ça peut poser problème quand l'ATS essayera
de basculer si l'arrivée elle présente un coeff de 0,9.

Globalement ça reste des équipements qui fonctionnent très bien quand ces
règles sont respectées scrupuleusement et qu'on surveille régulièrement les
infos qu'ils donnent (le plus important à mon sens étant le coeff phi).
Néanmoins ça reste un équipement supplémentaire et spof dans la chaine
d'alimentation auquel il ne faut pas non plus faire totalement confiance
(redonder le réseau quand même derrière me parait une bonne idée, juste au
cas où même si jusqu'à maintenant je n'ai jamais eu de coupure de sortie
d'ATS).

En espérant que ça vous aidera ..

Jérémy

Le 19 mai 2015 10:34, pub p...@noend.fr a écrit :

 En effet !

 Techniquement :

 Lorsque l’utilisation d’un STS reste impératif … il faut obligatoirement
 l’alimenter avec des disjoncteurs dédiés; ne jamais placer des machines
 double source sur les mêmes disjoncteurs que les STS …


 Financièrement :

 pas toujours intéressant !

 —
 Thierry

  Le 19 mai 2015 à 10:31, Gautier AVRIL gautier.av...@bretagnetelecom.com
 a écrit :
 
  +1 également,
 
  On a viré tous nos STS pour cette raison. L'alim qui crame et qui fait
 disjoncter une voie puis l'autre, ça arrive! : bilan, même les serveurs et
 switches qui sont doubles alimentés se retrouvent sans jus...
 
  Si c'est vraiment critique, il faut passer les serveur en double
 alimentation (et superviser qu'elles fonctionnent correctement), c'est la
 seule bonne méthode.
 
 
  Gautier


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


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

Re: [FRnOG] Marque Prix pour DWDM Passif ?

[Jérémy RIZZOLI]

 Oui Oui, je ne confond pas ! Quand je parle de DWDM dans les équipements
 en direct, c'est du 100G cohérent dans un optique Tunable ( ou non )
 direct dans le routeur.
 


OK, on est donc d'accord :)


 En trans coté ligne on sait faire du 100 G cohérent sur 1 longueur
 d'onde qui tient dans une grille DWDM de 50 Ghz standard (je vous laisse
 calculer l'occupation spectrale du Lambda, j'ai la flemme). (Soit
 potentiellement 88 * 100 G max sur une paire de fibre monomode)  --
 Aujourd'hui ça se vent déjà en masse aux google like, mais ça reste
 exclusivement OTN pour des raisons de traitement électronique et
 d'usages, transport donc !

 Dans le Metro, je reste persuadé que le 100G cohérent n'est pas encore à
 l'ordre du jour. De plus, les tests sont validés sur de la G655, beaucoup
 de fibre sont encore sur de la G652

 Si on regarde les dernières news sur le sujet, chez Adva par exemple :

 http://www.lightreading.com/document.asp?doc_id=211924utm_source=feedburne
 http://www.advaoptical.com/en/newsroom/press-releases-english/20110908.aspx
 ?utm_source=homepageutm_medium=tabsutm_campaign=20110908


 En effet je confirme, tout est questions de coûts ensuite aussi et c'est
vrai que pour le metro c'est peut etre un peu too much pour le moment. Après
en ce qui concerne le type de fibre ... c'est pas validé uniquement sur de
la G655 .. mais aussi et surtout sur de la G652 .. et de toute façon il y a
des variantes qui existent  (voir notamment pour le sous marin actuellement)


Le premier à le vendre et produire en masse est il me semble être Huawei,
 ALU ne doit pas etre super loin.


-- C'est fort possible, je suis pas trop au courant pour Huawei.


 Beaucoup de fournisseurs de waves sont actuellement soit en finalisation
 de validation, soit en cours de déploiement.

 Les densifications ne se verront pas avant au moins le début 2012. Je suis
 ( surtout en ce moment ) en relation quotidienne avec ces fournisseurs
 pour les upgrades ou re-nego de fin de contrat et tous ( 6 différents ) me
 le confirment.

 Certains sont sur de l'infinera qui n'a pas encore fourni le nouveau matos
 pour le faire. Il faudra surement attendre le 15 pour voir ce qu'il vont
 proposer ( http://www.infinera.com/webcast/us.php )

 
 On parle bien du coté client, le problème c'est que beaucoup font
 l'amalgame. Il faut bien expliquer que ce n'est pas n paires de fibre par
 optique, mais bien juste une fibre RX/TX. Ce qu'il se passe à l'intérieur
 de l'optique, la plupart des clients s'en fichent.


-- ça oui on est bien d'accord, mais faut quand même tenir compte de
l'occupation spectrale. C'est vrai que pour le moment, on s'en fiche un peu,
dans quelques années, on s'en fichera moins (quand on commencera à faire du
WDM en masse coté client aussi)


 Sur le 100G, c'est pour le moment réservé à très peu de personnes pour
 qui l'info est importante. Que ce soit 4*25 ou 2*50 importe peu pour les
 gens du réseaux.
 Eux, ils achetent un CFP-X supporté par le constructeur et donnent les
 specs aux gens de la transmission.


-- oui c'est sur :)


 La trans installe coté un CFP-X coté client ( on dira coté GRIS ) et la
 carte doit faire le boulot pour balancer le signal sur soit 4*25 ou 2*50,
 ou 1*100 sur le backbone WDM ( coté coloré).

 
 Après il existe aussi sur les 7750 notamment des cartes transpondeur
 100G Ethernet, mono longueur d'onde, détection cohérente, qui là aussi
 tiennent leur lambda dans une grille 50 Ghz. Ces cartes ont pour vocation
 de faire du 100G Ethernet Mono Lambda (qui en réalité passe sur une
 couche optique à base de G709). Don en gros même principe que les
 transpondeurs des équipements WDM .. d'ailleurs au passage, c'est quasi
 le même hardware de carte !

 C'est juste 2,5 à 3 fois le prix aussi. La force d'un constructeur
 aujourd'hui, c'est de proposer du matos et pour le longhaul et pour le
 métro. Si tu dois faire un Paris-Lyon pour tes besoins propre, et que tu
 n'aura jamais besoin de plus de 500G sur un seul path, tu peux tout
 simplement partir sur du 4 Waves pour 1*100G.
 Avec un filtre simple de 40 canaux, tu as déjà 1 Tera. Je viens de
 terminer l'exercice avec 2 constructeurs et en faisant le calcul IRU +
 MATOS et c'est plus rentable de tout migrer après 3/4 ans sur une nouvelle
 paire de fibre et changer les filtres et certaines cartes.

 100G cohérent sur tout un backbone c'est pour les très gros ou pour se
 faire plaisir. Dans la vrai vie, on va commencer à migrer dans 2/3 ans,
 pas avant.


-- On est d'accord, à mon sens pour le moment, l’intérêt d'avoir un agrégat
de N longueurs d'onde à 100G chacune est inexistant en France. Il n'y a peut
être que du coté des gros datacenters et Facebook like que c'est vraiment
utile et encore, que sur des tronçons vraiment très précis...
Ce qu'il faut voir aussi c'est que avoir une paire de fibre sur laquelle
passe n*100G .. quand la fibre claque, même avec une protection bien faite,
ça fait quand même très mal ...
Beaucoup de clients préféreront encore 

Re: [FRnOG] Marque Prix pour DWDM Passif ?

[Jérémy RIZZOLI]

Le 10 sept. 2011 à 23:03, Raphael Maunier - Franceix a écrit :

 Pas trop le temps de répondre en détail, mais j'aime bien la réponse de 
 Jeremy.
 Je répond plus a Michel qui doit cuver son vin :)
 
 On Sep 10, 2011, at 20:43, Michel Py mic...@arneill-py.sacramento.ca.us 
 wrote:
 
 Jérémy RIZZOLI a écrit:
 A priori, d'après les retours que j'avais eu des Labs, le meilleur
 compromis actuel pour le 100 G LR4 en fibre mono c'est 4 * 25G.
 
 Avec des lambdas de 50GHz je suppose?
 Ce qui contredirait ce que disait Raphael:
 Nope, aujourd'hui c'est sur fibre noire :)
 Du dwdm sur du 100g dans les équipements en direct c'est pas pour demain :)

Attention à ne pas tout confondre: 

En trans coté ligne on sait faire du 100 G cohérent sur 1 longueur d'onde qui 
tient dans une grille DWDM de 50 Ghz standard (je vous laisse calculer 
l'occupation spectrale du Lambda, j'ai la flemme). (Soit potentiellement 88 * 
100 G max sur une paire de fibre monomode)  -- Aujourd'hui ça se vent déjà en 
masse aux google like, mais ça reste exclusivement OTN pour des raisons de 
traitement électronique et d'usages, transport donc !

Bien sur, ça ne tient pas dans un module CFP une optique de ce genre, c'est des 
cartes transpondeurs dédiées et généralement la longueur d'onde est ajustable 
en sortie. ALU en fait en cohérent avec de la modulation PDM-QPSK (je ne sais 
pas pour les autres constructeurs, mais apparemment les modulations sont pas 
les mêmes)

En Ethernet, généralement, coté client des équipements WDM, sur les 
routeurs/switches donc, on sait faire sur un seul module CFP du 100 G LR4 avec 
4 longueurs d'ondes à 25 G chacune émises sur un PIC intégré dans le CFP (en 
sortie du module on a donc directement 4 Lambdas adjacents), tenant chacune 
dans une grille DWDM de 50 Ghz. A noter que du coup, plusieurs bandes de 
modules CFP existent et j'ai pas vraiment de détail sur la standardisation de 
ce coté, ni pour savoir s'il est possible de muxer directement le traffic 
venant de plusieurs CFP mais en tout cas c'est prévu pour ça (peut être un 
équipement intermédaire). 

La tendance semble s'orienter à terme sur du 2 * 50 mais là encore … rien de 
vraiment fixé et je pense qu'il y en aura un peu pour tous les gouts selon 
comment la norme Ethernet sera complétée .. A mon avis pour des raisons de 
couts de fabrication des PIC, le 4*25 est celui qui se vendra le plus et c'est 
déjà ce que disaient les labos ALU il y a un an. 
Pour le moment je n'ai vu que du 100G LR4 (comprendre Long Reach 4 Lambdas). La 
norme Ethernet du coté du 100G Ethernet sur modules CFP est en constante 
évolution et à mon avis de nouveaux standards sont encore à prévoir … Après ça 
dépend des distances et du type de fibre et de l'évolution des PIC !

Après il existe aussi sur les 7750 notamment des cartes transpondeur 100G 
Ethernet, mono longueur d'onde, détection cohérente, qui là aussi tiennent leur 
lambda dans une grille 50 Ghz. Ces cartes ont pour vocation de faire du 100G 
Ethernet Mono Lambda (qui en réalité passe sur une couche optique à base de 
G709). Don en gros même principe que les transpondeurs des équipements WDM .. 
d'ailleurs au passage, c'est quasi le même hardware de carte !

C'est un peu le même principe que le 10G WAN et LAN en gros…   WAN -- ça passe 
sur une couche sous jacente de transport (qui rajoute entre autres, FEC, 
alarmes, OAM et identification du lambda), LAN, ça passe sans la couche de 
transport en Ethernet direct mais moins tolérant aux pertes donc. Le module 
CFP ça restera le 100G du pauvre qui tend le plus à se démocratiser mais 
quand on veut faire du vrai 100G, c'est du 100G mono lambda ! et donc pas sur 
des CFP ..  (du moins pas pour le moment ! ).

un module 100G CFP ça bouffe 4 lambdas d'une grille 50 Ghz alors qu'un vrai 
transpondeur 100G ça n'en bouffe qu'un ! rapport de 4 .. 

La limite à ma connaissance aujourd'hui est d'adapter toutes les technos 
compatibles avec les multiples de lambdas sur une grille DWDM 50 Ghz qui semble 
devenir le standard, car il est quasi impossible de faire tenir un lambda à 
100G (même 40G) dans une grille 25Ghz pour des raisons de modulation, il 
semblerait que ce soit la limite, c'est 50Ghz mini.

Après, il y a aussi des équipements gridless qui arrivent sur le marché ou il 
est possible de combiner ensemble indifféremment du 50Ghz et du 100Ghz sur des 
longueurs d'ondes différentes, sur la même fibre. 
Cette tendance de grilles Adaptables semble être la prochaine tendance, mais 
pour le moment jamais encore vu en prod. 

 Séparer l'électronique du passif a toujours été notre méthode de travail. Ça 
 fonctionne sur du Metro et très peu de waves sur de la longue distance.
 Si tu veux du gros, tu es souvent obligé de prendre la solution du 
 constructeur 

Attention: 

électronique: par définition c'est de l'actif
optique: tu as les deux, passif ET actif

exemple d'optiques passive: un mux/demux, un module DCF, un coupleur optique .. 
exemple d'optiques active: un

Re: [FRnOG] Spanning-tree et STM4

[Jérémy RIZZOLI]

Le 5 août 2011 à 09:41, Radu-Adrian Feurdean a écrit :

 
 On Fri, 5 Aug 2011 06:39:04 +, Pierre Gaxatte
 pierre.gaxa...@gmail.com said:
 
 On a un lien STM4 
 Ce qui m'inquiète est que pendant l'incident, spanning-tree n'a pas fait
 de topology change
 Est-il possible que les BPDU continuaient à passer sur le VC restant mais
 
 STM4 + Spanning tree, on est effectivement vendredi...
 
 Si je comprend bien, le STM4 c'est du réseau commuté donc les chemins
 sont choisis à l'avance mais comment fonctionne la répartition du trafic dans
 les VC ?
 Ca bascule pas tout sur chaque VC en cas de coupure d'un des 4 ?
 
 Faudra nous expliquer nettement mieux cette partie de ton infra si tu
 veux vraiment de l'aide
 Genre : 
 - le lien est entre quoi et quoi
 - les circuits servent a quoi 
 - l'eventuel stacking de protocoles (X over Y)
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 

Si c'est un lien Ethernet over SDH via une méthode style GFP, alors tout dépend 
de la façon dont tes équipements terminaux gèrent la chose (en entrée sur la 
trans j'entend)

En général si on t'a vendu un STM4 équivalent c'est en fait 4 VC4 concaténés 
aux 2 extrémités via du LCAS. Ce qui ne veut pas dire que tes 4 VC4 passent 
tous au même endroit. La bonne logique voudrait même que ce soit 2 d'un coté de 
l'anneau SDH et 2 de l'autre si c'est bien fait :) (au minimum), ça peut aussi 
être 3 d'un coté et 1 de l'autre .. selon la façon dont ça a été programmé au 
départ, mais ça concrétement, c'est pas ton problème t'es pas censé le savoir 
en tant que client. 
Après il peut y avoir des protections au niveau SDH mais ça c'est transparent 
pour toi et concrètement on s'en fou un peu, c'est plus qu'éprouvé (basculement 
 50 ms)

En fait tout ton problème repose sur le LCAS. Si tu perds à un moment donné 
pour une raison purement trans, 3 VC4 sur 4, alors il ne te restera plus qu'un 
seul VC4 pour ton lien, soit un débit réduit à 130 Mbit/s utile en gros (en 
enlevant l'overhead). Ton lien continue de fonctionner mais en mode dégradé. 
Donc oui, si ton lien en temps normal est chargé dans les 500 Mbit/s tu va 
forcément voir un impact au niveau Ethernet et trafic qui passe dessus: trames 
perdues, retransmissions, etc etc .. mais de ton point de vue connexion 
terminale, tu continuera à voir le débit de l'interface Ethernet sur laquelle 
tu es connecté au niveau de l'équipement d'entrée sur le réseau trans. En 
général c'est un port 1 Gbit/s Ethernet classique, mais derrière ton débit est 
limité à 600 Mbit/s en fonctionnement normal avec du contrôle de flux 
notamment. Si 3 VC4 tombent, alors ton contrôle de flux freinera des 4 fers au 
niveau de l'équipement terminal pour lisser à 130 Mbit/s .. d'ou pertes de 
trames, retransmissions etc etc. 
Mais j'insiste sur une chose: ton lien restera up d'un point de vue Ethernet 
sur ton routeur connecté au point d'entrée trans, donc pas de déclenchement SPT 
ou autre. Simplement le contrôle de flux réduira le débit. 

Pour info ce comportement ça se paramètre généralement bien au niveau des 
équipements SDH qui font le point d'entrée Ethernet over SDH. Tu peux leur dire 
de couper le port ou de changer de priorité si le Lien agrégé tombe en dessous 
d'un certain débit. Après ça dépend des équipements et du paramètrage possible 
sur ces équipements ..  si c'est du vieux matos chez ton provider alors oublie 
:)

my 2 cents. 

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

Re: [FRnOG] Choix de techno de stockage SAN

[Jérémy RIZZOLI]

 Bonjour,
 
 Nous savons tous les 2 ce qu'une fiche produit peut dire mais que la réalité 
 voit de façon différente.
 Donc, la solution serait de monter un test et voir ce que ça donne.
 
 Rien de tel qu'un Proof Of Concept ce qui évite des déboires de paroles pas 
 tenue, performance médiocre ou autre et surtout de juger d'un rapport 
 prix/perf car oui il y a des abus je trouve dans le domaine ;p
 
 Je peux voir avec NEC si tu veux et ainsi répondre à tes questions avec des 
 chiffres.
 Je pense obtenir le soutien du constructeur sans problème d'autant que leur 
 staff technique France est à 1h de route d'ici au besoin.
 
 ++
 Vincent

-- Si c'est possible d'avoir des chiffres réels en effet ça peut être pas mal. 
Le truc c'est que je suis assez limité en temps malheureusement pour faire un 
choix et à la vue des premiers retours que j'ai eu, même DELL a du mal à nous 
apporter une réponse concrète sur le sujet. 
Seul le retour d'expérience peut je pense être bénéfique. 

Mais plutôt qu'un PoC peut être que simplement d'autres personnes sur la 
mailing liste ou dans vos DSI respectives ont déjà expérimenté du stockage de 
VM sur des SAN en SATA. .. on n'est probablement pas les premiers à 
s'interroger sur le bien fondé du SAS et de ses prix excessifs.. 

dans tous les cas je commence a avoir ma petite idée de la question grâce à vos 
différents avis. Merci ! 

--
Jérémy---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Choix de techno de stockage SAN

[Jérémy RIZZOLI]

Merci beaucoup pour la réponse,

Effectivement dans notre cas, le temps de latence n'est pas un facteur
limitant, on peut se permettre sans problème d'avoir des temps de latence
plus importants, même sur les VMs, d’où l'idée de partir sur du SATA pour
des raisons de coûts.

Mais jusqu’à maintenant je n'avais pas vraiment de retour sur les usages
possibles ou non en SATA.
En ce qui concerne les IOps, les stats que j'ai aujourd'hui en prod me
semble assez faibles au regard de ce qu'il doit être possible de faire si je
me fie à certaines docs trouvées sur le net:
http://www.storiq.com/fichiers/perfs-storiq-2011.pdf

Je tourne aujourd'hui à 500IOp/s max sur mon SAN sas, je pense que du SATA
doit pouvoir faire la même chose avec autant de disques
En terme de débit, je dépasse pas les 20 Mo/s autant dire que mes disques
SAS se tournent les pouces .. donc je pense que pour le SATA ça sera
globalement pareil.

Pour ce qui concerne le RAID, effectivement, pour limiter le nombre
d'opération sur chaque disque, on pensait partir sur du RAID10 au lieu de
RAID6 qui semble moins lourd en terme de charge contrôleur et qui permet une
meilleure fiabilité tout en limitant les IO sur le SATA. Et comme les
disques SATA sont plus gros, ça limite moins aussi.

Et en ce qui concerne la place dans les baies, ce n'est pas un facteur
limitant non plus, du coup votre avis confirme vraiment ce que je pensais au
départ.

Merci !

Jérémy

Le 12 avril 2011 10:15, SEGOUFFIN, Pascal psegouf...@tf1.fr a écrit :

  Bonjour,



 En sus du nombre d’io il te faut prendre en compte la latence, les deux
 n’étant pas forcément lié. A titre d’information, j’utilise un peu tout les
 style de disques (en NAS seulement dans mon cas, je ne suis pas très SAN ni
 ISCSI J ).



 Quand aux iops par disque ce qui est intéressant c’est plus la différence
 entre les technologies plus que les perf elles mêmes, dans la mesure ou cela
 change en fonction du type d’io et du type de données.



 Dernier point, le type de raid influe sur les iops globaux également, sur
 tous les raid tu as généralement 1 io read pour 1 io demandé, par contre sur
 les write ca change pas mal (raid 1, 1w demandé = 2 write, raid 5  - 4
 write, raid 6 - 6 write).



 De notre coté on utilise le SATA quand on a besoin de stocker des archives
 ou des données sur lesquelles la latence importe peu (15 ms et plus), comme
 les gros fichiers vidéo par exemple.



 Le SAS ou les disques fibre, on les utilise uniquement sur les applications
 ou on à besoin de latence faibles  comme les bases de données et les VM.
 L’autre raison et bien c’est que ca occupe moins de place dans les baies
 d’utiliser du SAS ou des disques fibres quand tu n’as pas besoin de fortes
 capacité de stockage mais que tu as besoin d’io et donc besoin d’augmenter
 le nombre d’axes disques.



 Cldt.





 *De :* owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] *De la part de
 * Jérémy RIZZOLI
 *Envoyé :* mardi 12 avril 2011 00:55
 *À :* Vincent Duvernet (Nolmë Informatique)
 *Cc :* FRnoG Liste
 *Objet :* Re: [FRnOG] Choix de techno de stockage SAN



 Bonsoir,



 je précise un peu:



 On a actuellement du PS6000XV (c'est à dire haut de gamme) avec 16 disques
 SAS 15k dedans en RAID6 (2 disques de spare) -- ça nous a couté un bras
 pour relativement peu d'espace utilisable



 Le monitoring SNMP nous indique une moyenne a peu près constante de 500
 Iops (ce qui me semble assez peu au regard des capacités potentielles du
 SAS)

 En terme de débit, on sous utilise largement je pense (je vous confirme ça
 demain)



 chaine iSCSI dans un réseau dédié donc pas de pb de BP de ce coté, redondé
 comme il faut.



 Environ une 60 aine de VM qui tournent dessus (Disques système + ramdisk +
 swapfile). Evolution prévue a une centaine de VM (principalement des OS
 FreeBSD + Linux) . Toutes les BDD sont hébergées sur des volumes séparés
 dans un SAN à part en RAID10 donc pas de pb de ce coté)



 A l'heure actuelle on viserai un PS6500E pour extension du PS6000XV actuel
 avec 48 disques en SATA 1 To dedans. On pense que niveau perfs ça suffirait
 amplement étant donné ce qu'on utilise aujourd'hui mais voilà, difficile
 d'avoir des données chiffrées sur les possibilités de la bête .. même les
 commerciaux DELL ont du mal à nous les filer



 l'idée au final serait d'étendre l'existant à moindre cout avec un max de
 capacité (meilleur rapport prix/Go):



 PS6000XV (16*300Go) pour stocker tous les disques systèmes des VMs ayant
 besoin d'un peu de perf



 PS6500E (48*1To) pour les disques secondaires à but de stockage de fichiers
 pur ainsi que des disques systèmes de VM n'ayant pas de gros besoins en
 perfs (environ une 60 aine à terme je pense): usages typiques: serveurs
 d'appli web/mail, serveurs FTP, serveurs de développement



 Je précise qu'on a découpé le PS6000XV en volumes logiques de 200 Go
 d'après les recommandations de VMware (environ 10 VM par volume de 200 Go),
 on peu envisager de faire pareil sur le PS6500E si

[FRnOG] Choix de techno de stockage SAN

[Jérémy RIZZOLI]

Bonjour à tous, 

je pose une question sur cette ML en espérant trouver ici des avis éclairés sur 
la question du choix entre techno SAS (15K), NL-SAS (7,2K) et SATA dans un SAN 
iSCSI. 

je précise un peu: On a des DELL Equalogic PS6000 qui tournent pas mal avec un 
RAID6 dessus, le tout accessible sur nos hyperviseurs via iSCSI. Actuellement 
on utilise des disques SAS 15k dedans. 

ma question est la suivante:

Y a t-il quelque part de vrais comparatifs purement chiffrés et concrets de 
performances entre du SATA standard, du NL-SAS et du SAS 10 ou 15k ? la 
question se pose surtout au niveau des perfs en termes d'IO, sur un RAID 6 à 
base de ces disques. Et si on peut trouver un comparatif qui tienne compte de 
différents contrôleurs hardware ce serait encore mieux !

l'idée est de voir si le SAS 15K est réellement justifié dans notre cas pour 
savoir s'il serait envisageable de n'avoir que des disques SATA, voir NL-SAS à 
la place pour des raisons de cout. Est-ce que quelqu'un s'est déjà posé la 
question ? Etant donné les différences de tarifs/Go entre SAS et SATA ... la 
question se pose clairement pour un cas comme le notre où les perfs ne sont pas 
vraiment une priorité (on cherche avant tout de la place, beaucoup de place).

Pour préciser, notre usage actuel du SAN c'est du disque purement système de 
différentes VM qui tournent sur un ESX (pas de database) + un peu de stockage 
pur et dur 

Merci d'avance pour le retour 

Cordialement 

Jérémy RIZZOLI---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Choix de techno de stockage SAN

[Jérémy RIZZOLI]

Bonsoir, 

je précise un peu: 

On a actuellement du PS6000XV (c'est à dire haut de gamme) avec 16 disques SAS 
15k dedans en RAID6 (2 disques de spare) -- ça nous a couté un bras pour 
relativement peu d'espace utilisable

Le monitoring SNMP nous indique une moyenne a peu près constante de 500 Iops 
(ce qui me semble assez peu au regard des capacités potentielles du SAS)
En terme de débit, on sous utilise largement je pense (je vous confirme ça 
demain)

chaine iSCSI dans un réseau dédié donc pas de pb de BP de ce coté, redondé 
comme il faut. 

Environ une 60 aine de VM qui tournent dessus (Disques système + ramdisk + 
swapfile). Evolution prévue a une centaine de VM (principalement des OS FreeBSD 
+ Linux) . Toutes les BDD sont hébergées sur des volumes séparés dans un SAN à 
part en RAID10 donc pas de pb de ce coté)

A l'heure actuelle on viserai un PS6500E pour extension du PS6000XV actuel avec 
48 disques en SATA 1 To dedans. On pense que niveau perfs ça suffirait 
amplement étant donné ce qu'on utilise aujourd'hui mais voilà, difficile 
d'avoir des données chiffrées sur les possibilités de la bête .. même les 
commerciaux DELL ont du mal à nous les filer

l'idée au final serait d'étendre l'existant à moindre cout avec un max de 
capacité (meilleur rapport prix/Go): 

PS6000XV (16*300Go) pour stocker tous les disques systèmes des VMs ayant besoin 
d'un peu de perf  

PS6500E (48*1To) pour les disques secondaires à but de stockage de fichiers pur 
ainsi que des disques systèmes de VM n'ayant pas de gros besoins en perfs 
(environ une 60 aine à terme je pense): usages typiques: serveurs d'appli 
web/mail, serveurs FTP, serveurs de développement

Je précise qu'on a découpé le PS6000XV en volumes logiques de 200 Go d'après 
les recommandations de VMware (environ 10 VM par volume de 200 Go), on peu 
envisager de faire pareil sur le PS6500E si ça nous permet d'améliorer les 
perfs ...

-- on cherche à estimer les capacités en termes de perfs du 6500E vu qu'il 
repose sur du SATA afin de voir si ça suffira ou non pour notre usage, les 
questions qu'on se pose principalement c'est: 

Est-ce que le SATA induit beaucoup plus de charge sur les contrôleurs par 
rapport au SAS ?
Quel type de RAID le plus adapté par rapport à la fiabilité du SATA entreprise 
? (RAID6 ou RAID10) ?
Quel différences réelles entre du SATA vendu par DELL avec les SAN et du SATA 
du commerce (genre un disque de 2 To à 70 euros) ?
Quel différence flagrante en termes de perfs à part les temps d'accès moins bon 
sur du SATA (probablement lissés par le contrôleur quand même) ? 
Combien de VM peut-on espérer faire tourner dessus sans trop plomber les perfs 
et la fiabilité, ou plutot: IOps max, débit max écriture/lecture séquentielle 
et aléatoire, etc..
 
Merci pour votre aide. 

Jérémy


Le 12 avr. 2011 à 00:07, Vincent Duvernet (Nolmë Informatique) a écrit :

 Bonsoir,
 
 ta question est encore un peu vague selon moi.
 On peut toujours trouver plus rapide c'est une question de prix. Le tout est 
 de savoir si tu en as besoin.
 As-tu du monitoring SNMP ou autre qui pourrait donner un ordre d'idée du 
 débit pompé en pic et en moyenne ?
 Combien de VMs tournent dessus ?
 Est ce que ta chaine iSCSI tourne sur un subnet différent de celui de tes 
 datas ?
 Ta baie iSCSI est pleine (16 disques c'est bien ça ?)
 
 ++
 Vincent
 
 -- 
 logo.gifVincent DUVERNET
 Directeur Technique
 Certifications:
 Kaspersky Lab, Netgear
 VMWare VSP/VTSP, Cisco Select SMB
 Nolmë Informatique
 Lieudit La Fontaine
 61170 LALEU
 FRANCE
 Tel : (+33)2 33 27 30 96
 E-mail :  vincent.duver...@nolme.com
 Web : http://www.nolme.com

Re: [FRnOG] Re: Green IT et Internet

[Jérémy RIZZOLI]

Bonsoir à tous, 

Tout le monde le sait, l'industrie IT est probablement la plus polluante qui 
soit, et on aura beau dire il faut changer, je ne suis pas certain que cela 
changera vraiment un jour car même si on vivait dans un monde de bisounours et 
que l'électricité était produite à l'infini par ITER et sa fusion 
thermonucléaire, il y aura toujours le problème du retraitement des déchets 
générés par l'IT et par n'importe quelle industrie, je pense notamment: 

-A toutes nos vieilles machines , PC, gsm, serveurs , écrans cathodiques.. que 
les centres de retraitement n'arrivent pas vraiment à absorber .. ne parlons 
même pas des pays comme la Chine qui ne retraitent quasiment pas -- c'est 
autant de gaz nocifs, produits toxiques et métaux lourds qui finissent tôt ou 
tard dans la nature sans retraitement.. 
-A toutes ces voitures un peu vieilles qui sont parties à la casse grâce au 
super bonus de notre gouvernement, résultat les casses sont surchargées et ça 
engendre forcément des problèmes .. (sauf pour les constructeurs)
-A tout ces coeurs CPU qui sont aujourd'hui dans toutes nos machines et qui 
sont proportionnellement à leurs capacités beaucoup trop peu exploités 
utilement. 
-A tous ces vieux brasseurs énormes qui consomment à mort , que les opérateurs 
s'acharnent à garder en vie par nécessité et dont on change les cartes beaucoup 
trop souvent parce qu'ils ne sont plus fiables et plus adaptés aux besoins 
actuels  .. 

Bref, tout ça pour dire que chaque vague de nouveaux produits, nouvelles 
technos, et la tendance GreenIT qui dit il faut tout changer pour consommer 
moins engendre forcément des problèmes collatéraux bien plus importants que le 
simple rejet de CO2. 
Plutôt que de laisser nos grandes entreprises aller fabriquer leurs produits 
high-tech en Chine là où elle peuvent polluer sans trop payer .. on ferait 
mieux de s'inquiéter de l'ensemble de la chaîne de retraitement/valorisation 
dans le monde avant de parler de GreenIT. 

Selon moi ne serait-ce que parler de GreenIT démontre bien à quel point ce 
vrai problème de réchauffement climatique est tourné à la dérision et 
transformé en opportunité commerciale exceptionnelle susceptible de venir 
relancer la consommation .. 
De toute façon il faut être réaliste: énormément de gens sont équipés en 
informatique/réseau aujourd'hui, on est loin de l'époque où Internet provoquait 
la course à l'équipement, par conséquent on vendra forcément de moins en moins 
de produits dans tous les secteurs IT jusqu'à arriver à saturation du marché. 
Le renouvellement n'est justifié que par la nouveauté.. qui engendre des 
déchets supplémentaires à retraiter. Alors oui, il faut de nouveaux produits 
plus écolo pour ceux qui s'équipent aujourd'hui, mais de là à dire qu'il faut 
remplacer l'actuel qui fonctionne juste pour être green et tendance ..  

Bref .. le monde des bisounours il est encore loin.. 

Le Jan 27, 2010 à 10:00 PM, Thioux nicolas a écrit :

 Bonsoir à tous,
  
 Je pense qu'après ces détours vers le nucléaire (et le réseau des centrales, 
 il est vert ?), une petite redynamisation s'impose !
  
 On a parlé des datacenters dans tous les sens, mais les équipements passifs 
 et actifs propres aux réseaux/télécoms beaucoup moins, même si certains 
 équipements sont intégrés dans les salles serveurs, ils restent de nombreux 
 matériels entre les utilisateurs finaux et leurs sites et applications 
 favorites.
  
 Qu'en est il pour le cycle de vie des équipements passifs - fibre, paires de 
 cuivre, répartiteur.. - et les équipements actifs - switchs/routeurs de type 
 SoHo (domicile, bureaux) , et la gestion de leur consommation énergétique, 
 de leur recyclage ? - Que faites vous chez vous ? et au boulot, aidez vous 
 vos clients, est-ce que vous les conseillez ?
  
 On ne prête pas forcément attention au cableur qui vous enlève du cat5 et 
 vous met du beau 6 tout neuf : ou va le cable ? à la benne ? ou existe t'il 
 des filières que vous utilisez ? et le petit Cisco 828 obsolète que vous 
 remplacez par un beau gros boitier au top mais qui fait tourner son ventilo 
 à fond pour.. le même résultat ? qu'en pensez-vous ?
  
 Bonne soirée
  
 Nicolas
  
 
 
  
  http://router-ecologique.blogspot.com/
 L'écologie appliquée aux Réseaux et Télécommunications
 
 
 --- En date de : Lun 25.1.10, eberkut eber...@minithins.net a écrit :
 
 De: eberkut eber...@minithins.net
 Objet: Re: [Bulk] [SPAM-POSSIBLE]Re: [FRnOG] Re: Green IT et Internet
 À: Liste FRnoG frnog@frnog.org
 Date: Lundi 25 Janvier 2010, 2h05
 
 
 Le 24 janv. 2010 à 21:19, thierry yahoo a écrit :
  Jiw a écrit :
  
  
 tout ca pour dire, que non le nucleaire ce n'est pas (encore)
 propre mais c'est pour le momant le moins pire.
  
  
  Les dechets nucléaire, c'est tellement propre qu'on a trouvé l'endroit
  idéal pour le stocker: votre salon !
  
  En mai dernier, le gouvernement a publié un arrêté autorisant l’ajout de
  substances radioactives dans les biens de consommation