Reprise du message précédent :
Sinon oui +1 pour Arista, t'as plein d'API et accès au sous-système linux si tu veux, ils ont de quoi faire plein de ports 400G, mais bon ça coûte proportionnellement même si c'est souvent moins cher que Cisco/Juniper. Je plussoie Ivy gu sur le fait que fabriquer un switch ne s'improvise pas, mais t'as pas l'air de t'inquiéter donc tu as peut-être de l'expérience sur des projets similaires d'intégration avec une puce 3rd party.

Ca donne envie de rebosser ça

 
Quand je parle de switch je parle de la puce en silicium elle-même.
Il y a une puce silicium qui domine le marché et que l'on retrouve dans plus de la moitié des switch "boitier" : Broadcom Tomahawk 3 et 4. Il y a un peu d'Innovium Teralynx. Je sais que Marvell a une puce mais j'ai pas entendu parlé d'implémentation et après il y a Cisco qui a fait son ASIC.
On a pas $10k à mettre dans la R&D en PoC. Le réseau n'est pas du tout notre coeur de métier, le domaine où on est travaille sur d'autre types d'interface. Avant on utilisait un protocole propriétaire pour interfacer des machines. Aujourd'hui il y a un shift vers l'Ethernet.  
On peut claquer $3000 dans le switch (composant) sur le produit fini et les proto. En revanche on n'a pas les moyens de faire 2 versions en parallèle, 1 Xeon et l'autre SoC ARM.
Pour simplifier, le SoC/CPU est interfacer avec un lien Ethernet à un autre SoC qui gère tout l'appareil.  
 
On parle "d'embarqué", de produit custom. Pas de prendre un rack serveur 1U avec un rack switch 1U et faire des connexions    
 

 
Normalement l'utilisation que l'on a c'est sur un réseau fermé que l'on contrôle (dans le sens où on connecte les cartes dans le chassis au switch), ce 400G n'est en aucun cas relié à un réseau externe. On regarde le 400G car c'est un gros débit disponible sur le marché qui nous évite de rentrer dans des solutions propriétaires encore plus chères. Il n'y a pas de protocoles avancés, à la base c'est une machine dédiée, donc un switch, à la limite il y a aura 2 ou 3 switch maximum (3 machines reliées ensembles).
 
L'autre point, je parle de Sonic car c'est open source et finalement utilisé sur du 400G. Et c'est surtout le seul moyen d'avoir un NOS sur un switch custom, après y a Cumulus mais c'est payant. Et dans notre business, on vend une machine en one shot, pas un abonnement. Or devoir payer une license pour l'OS du switch, ça me paraît compliquer à faire facturer au client. On est en phase de pré-étude, donc le but est de voir ce qui est disponible et d'expliquer les avantages et inconvénients.
 
Sur la partie switch "boitier" on a une utilisation possible, en parallèle où on "explose" la machine et on branche les éléments sur un switch boitier. Personnellement je regarde la liste de Sonic principalement du whitebox. Le but étant sur un HW custom de réutiliser le même switch IC et le même nOS pour qu'en interne on n'est qu'un OS à gérer et pas un cisco + cumulus/Sonic.
 

Ah enfin un peu de bon sens  

En dehors des trucs un peu louche comme la QFabric, Juniper propose des produits pour tout le monde.

Ma dernière expérience j'ai fait une carte embarqué avec un switch 5 x 10G Br04dc0m. Y a rien de complexe, un switch t'as une API pour le contrôler, c'est fourni par le fabricant, donc soit tu prend l'API et tu l'intègre dans ton code ou OS maison.
Soit, j'ai découvert ça, tu as les network OS open source, dont Sonic qui sont supportés par les fabricants de switch et donc le travail d'intégration de l'API est déjà fait. Il y a surtout un travail sur l'utilisation du network OS et dans le cas de ma boite de formation réseau. (On pourra toujours demander de l'aide au service info )

Non ça ne s'improvise pas, c'est mon boulot de concevoir des cartes électroniques.  
Je dis pas que c'est facile, mais un switch c'est vraiment un truc facile par rapport à des composants de même taille. Ensuite on discute avec les fabricants pour avoir la documentation et on a du support. (Mon poste précédent j'étais en relation avec M4rv3ll et Br04dc0m pour utiliser un switch 25G avec des SoC/FPGA, donc bon rassurez-vous j'suis pas stagiaire ).
Un switch en soi c'est très con : une partie ASIC que tu contrôle via des registres, une interface de contrôle en PCIe au CPU et une API qui permet d'avoir des commandes simples plutôt que d'aller taper une valeur à une adresse de registre.
L'API du switch existe donc c'est pas ça le problème majeur.

Mais surtout j'essaie de ne pas avoir une vue strictement HW. Je sais bien que ça sert à rien d'envoyer du rêve si derrière le SW ne peut pas faire grand chose.

 
ok bon, $3000 ça me semble ridiculement bas comme coût de développement.
Ceci mis de côté, prends peut-être déjà contact avec les différents fondeurs (déjà rien que pour voir s'ils acceptent de te parler, je ne sais pas de quels volumes on parle mais ça va sûrement avoir une importance), ça te permettra de savoir s'il y a des limitations en terme d'architectures CPU supportées pour leur API, et ils auront peut être aussi des guidelines en fonction du cas d'utilisation que tu vises.

$3000 c'est le coût de la puce, pas le développement    
Là c'est de la pré-étude. Oui contacter les fabricants est prévu mais on est une petite boite donc effectivement le risque c'est de se faire dégager même si sur ce type de produits, je pense que c'est un peu moins le cas. Ce que n'aime pas les grosses boites c'est la partie logistique/compte client. Mais surtout faut venir avec un projet un peu crédible avec des volumes d'achat et tout, ils aiment pas trop la pêche aux infos.
 
Je le répète, je vise l'utilisation de Sonic qui est passé sur architecture ARM récemment. En regardant le github tout ce qui fonctionne sous x86 a été porté sur ARM. Sachant que les switch ont souvent des coeurs ARM intégrés, les API sont plutôt faites pour du ARM que du x86 à la base. Je ne m'inquiète pas trop pour ça. Et pour éviter du portage d'API le but est de reprendre des puces déjà utilisées dans des switch 400G existants
 
 

 
Et puis pour prototyper tu prend un Arista en refurb à pas cher et tu vois si ça peut répondre au besoin

Bonjour,
 
quelqu'un a des retours sur des distros Linux pour du NAS ?
 
Je louche sur TrueNAS mais il ne fait pas de tiering
 
L'objectif est de monter un datastore via NFS pour une infra sous vSphere; dans le cadre d'un lab.

Quand j'ai hésité à quitter Synology, Unraid (payant, mais très abordable) m'a semblé top.

TrueNAS ça fait pas de tiering Avec ZFS ça devrait, entre ARC (RAM) et L2ARC (SSD), ZLOG (ack write avec genre NVMe si jamais ta besoin) et finalement tes HDD.

Openmediavault mais c'est plutôt end-user et le dev est un con

Sinon t'a les descendants de Freenas (mais c'est du BSD).
Mais t'aura pas de vrais tiering comme sur un SAN pro, avec différents niveaux de stockage...

les ARC/L2ARC et autre ZIL SLOG ce sont plus des Gros caches pour compenser les HDD derriere et/ou encaisser le Burst.
Ce n'est pas le tiering que tu peux trouver dans les SAN, je confirme.

Donc en gros les SAN dont vous parlez vont déplacer les données entre les SSDs et les HDDs en fonction de l'utilisation, pas faire de copie des données les plus utilisées dans les SSDs par exemple

C'est ça. Mais ça va plus loin que juste HDD/SSD. Ça peut être sur des array raid différents, des HDD plus ou moins rapides, de la tape, du cd/DVD/random truc optique, du déport dans S3/glacier, ...
Ou des stockages avec plus ou moins de redondance.

 
Non c'est l'objectif du tiering : placer les données sur l'espace de stockage le plus approprié en terme de besoin (temps d'accès, débit, IOps).
Le gain : un moindre coût du stockage puisque les données mortes ou peu accédées vont être placées sur des médias pas chers; typiquement des HDD 7.2k.
 
Aujourd'hui, dans les entreprises, y'a des To de données qui ne bougent quasiment pas et/ou nécessitent peu de perfs et qui sont hébergées sur des SSD ou SAS 10/15k.

et surtout c'est géré de manière transparente et automatique !

C'est bien ce que je dis
 
Cache : copie des données les plus utilisés dans les systèmes plus rapides
Tiering : même chose mais par déplacement (et non copie)

Pas forcément déplacement, ça peut être le placement de départ aussi.

 
oui mais au final ca reste des deplacements

 
Et comment tu gères le placement de départ sans connaître le degré d'usage de ta data (à part un placement par défaut ou alors faire passer l'info au SAN ?)

Euh, bah, je vois pas comment ?
Si dès le départ le san stock la donnée sur l'array machin parceque raison X, c'est du tiering, mais il l'a déplace pas ?

T'a pas que l'usage qui rentre en ligne de compte. Ça peut être une classif de donnée ou un metier aussi (genre, données de compta sur de la double redondance).
Ça peut s'intégrer avec ta solution de virtu par des politiques ou des tags (genre les storage policy vSan).

Des utilisateurs actifs d'oxidized? (j'ai juste trouvé un vieux poste où Xat s’apprêtait a tester, couplé à libreNMS: ça a donné quoi? )  
 
d'autre produits à recommander pour du "versionning" basique de configs de switchs aruba et *sense.  

M'sieurs D'ames,
 
Qqn tourne du couchdb par ici ? J'ai une question au niveau backup.
 
J'ai un utilisateur avec 2 serveurs qui tournent, ces 2 serveurs sont répliqués.
 
De mon côté je fais un backup de ces serveurs avec rsnapshot mais comme son couchdb fait dans les 1Tb, ça bouffe environ la même taille par jour sur mon serveur de backup et je me dis que ce n'est pas tant optimisé comme histoire.
 
Sur le site de couch ils proposent la réplication comme "backup" mais dans ce cas, si des données sont supprimées sur le premier serveur, ça se répliquera sur les 2e non ? ou je n'ai pas saisi un truc
 
Bref du coup je me demandais
- c'est quoi la bonne pratique pour backup ce genre de choses ?
- mes rsync journaliers sont t'ils utiles au final ou même pas ?
 
Merci

Kiwi CatTools  

Bah ça marche
Avec librebms j'ai fait des essais, ça marchait mais j'ai pas dépassé ce stade.
Oxidized lui est en prodeuh

Oxidized couplé a librenms + synchro git    
 
bon le link avec librenms c'est rigolo mais je trouve pas ça utile (je n'ai qu'une 30aine d'équipements)
l'interface Oxidized je m'en sers jamais.
par contre le git c'est top. tu repères direct quel device a changé de conf, quand et le diff bien propre.

git c'est trop compliqué

qu'aux mÿthes, pouche, poule  

Sinon à la place, NeDi ? Ça a l’air de coller au besoin

@Xat et exeral
oui, c'était justement quand j'allais mettre en place un git en place pour le suivi des confs que j'ai croisé oxidized qui semblait le faire pour moi . merci pour réponses, je vais tester  
 
@Saguu: je jette un oeil a nedi  

NeDi, $job[-1] l'utilisait sauf que c'est pas moi qui l'avait setup.
du coup je l'ai envisagé a la place de LibreNMS à $job[current]. j'ai commencé a le setup mais j'ai lâché l'affaire. trop compliqué. pas plug'n'play.
J'ai trouvé librenms beaucoup plus simple.

Dans votre PRA vous avez une option de récupération des données archivées ou sauvegarde tiers hors site via une solution comme la livraison de HDD ? ou autre ?
dans le cas où la BP/latence/whatever serait un bottleneck trop important pour réaliser une restauration en un temps correct

 
Ici la solution c'est un job supplémentaire le weekend (Cont. replication des VMs via XO sur un hôte dans nos bureaux).
 
L'alternative (qui va arriver) c'est le backup asynchrone (sync sur le storage rapide à côté, et async sur le storage éloigné)

Ils ont quelles gueules vos CV ?
 
Je dois refaire le mien, qui à plus de 13ans et qui ne ressemble donc plus à grand chose. Oui on peut le dire, il est moche    
 
J'aimerai bien faire un CV un peu "original".
Il y a bien des centaines de template sur le net mais payant et bof quoi, les recruteurs doivent déjà les connaitres.
 
Il existe des outils pour faire ça à part word/libreoffice ?
 
latex je ne connais pas, je pensais en MD, mais bon après faut le sortir en pdf

J'ai refait le mien ya pas si longtemps, il est passé de "sobre & fonctionnel" et assez basique à "on dirait un flyer" d'après quelques amis Pourtant le contenu n'a pas dramatiquement changé, c'est surtout la forme qui met mieux en valeur le contenu et attire l'oeil.  
J'ai suivi quelques videos de tutoriels sur youtube puis adapté comme je voulais, 100% word mais ça doit pouvoir se faire sous n'importe quel traitement de texte qui a 2-3 notions de formes graphiques.  
 
Exemple de video : https://youtu.be/Yeg29d5mxJY

J'ai fait l'erreur de faire mon premier sur publisher, beaucoup plus souple pour faire de la mise en page type flyer que Word, mais il a l'air vieux et moche quand même

mon tout premier était super, coloré viteuf stylé manga
Ca reprenait un peu l'interface de ragnarok online, trop beau
 
Étonnamment j'ai été pris
 
Les suivants étaient basique et maintenant je me fais pas spécialement chié

tin je backup pas mal de disques, et bah uploader des repos SVN sur un cloud ça fait mal (en terme de perfs)