Bonjour à toustes,
Travailleur de l'informatique depuis une quinzaine d'années, j'exerce
depuis 5 ans comme ingénieur réseau, système et sécurité dans les télécoms
après une formation en 2020 et suis à la recherche d'un emploi en
administration réseau sur Paris ou IDF, en CDI ou Freelance.
Autodidacte depuis l'adolescence, j'ai commencé dans l'IT en faisant du
support avant de progresser vers le métier d'admin, tout en bidouillant
pour mes usages perso et pour des associations avec des logiciels libres
et/ou open source.
J'aime travailler avec des systèmes Linux, Debian et Fedora principalement,
mais ne rechigne pas à travailler avec du Windows.
À travers mon parcours, j'ai pu me familiariser avec les matériels réseau
Unifi, Cisco Meraki et Mikrotik, des pare-feux Stormshield et Netgate
(PfSense), de la virtualisation avec ProxMox et Hyper-V, de la VOIP avec
3CX et FreeSwitch.
Je sais m'adapter aux besoins des clients et des entreprises avec
lesquelles je travaille, improviser des solutions pour résoudre des
problèmes et faire face aux aléas.
Vous pouvez télécharger mon CV complet ici:
https://mia.gasy.me/index.php/s/xNLAWsBBgFmXNf8
Je reste dispo pour toute information supplémentaire,
Bien à vous,
Nicolas
Bonjour Pierre-Philipp, Xavier
Désolé pour la réponse tardive, je ressorts mollement d'une grippe
intéressante, la dernière datait de 2016. Il en faut de temps en temps
pour maj le SI :)
>>> Perso je suis un fan de DRBD et ils ont un module pour les longues
>>> distances https://linbit.com/disaster-recovery/
>> Cette option ne semble pas libre, mais c'est intéressant :)
> je sais pas si DR est libre ou pas, ce serait dommage car DRBD
> lui-meme est bien libre. https://github.com/LINBIT/drbd
Linbit a toujours eu un mal de chien à monétiser son travail. DRDB est
libre mais tout ce qui tourne autour ne l'est pas... trop.
>> J'avais des résultats allant de spectaculaires à plantés (sans
>> vraiment comprendre parfois). Bon en local ça marche, mais de DC à
>> DC... J'ai trituré toutes les options possibles pour voir, testé DRDB
>> 8 et 9 (à l'époque, je ne sais plus où ils en sont). Je dois être
>> moins doué qu'AWS ;>>>
>
> moi j'ai des bon resultats en terme de perf et je pense que j'ecrase
> Ceph RBD assez facilement. ce serait normal d'ailleurs, car il n'y a
> aucun overhead (pas de hash table ou d'algo de distribution, juste des
> configs qui point vers des paires de noeuds variees). en plus c'est
> ideal pour un cluster convergent, c'est meme fait pour, alors qu'avec
> Ceph RBD faut quand meme se poser la question de savoir si les noeuds
> supporteront la double charge (virtu + stockage). Bon et puis CephFS
> il n'y a pas le choix, c'est force'ment un autre cluster de'die', mais
> c'est un autre cas d'usage.
CEPH n'est pas KISS. Ce simple fait suffit à ne pas aller plus loin pour
moi. DRDB est KISS, mais...
> je joue beaucoup avec. Je fais des cluster XEN et utilisais LVM2 et
> maintenant OpenZFS zvol **sous** les resources DRBD. il faut noter
> que DRBD v8 inclus dans le noyau nunux fait simplement des mirrors,
> alors que DRBD v9 sait aussi faire du diskless, donc un noeud qui n'a
> pas de mirroir local peut aussi voir les volumes.
Oui. J'ai testé les deux. DRDB9 a plus de possibilités, comme d'avoir n
miroirs (1 master 2 slaves, ça peut être bien).
Pas testé avec ZFS, je croyais même que ZFS et DRDB étaient incompatibles...
> J'ai aussi fait des tests avec les snapshots, c-a-d qu'on peut faire
> des templates sur des vdisk normaux (des resources DRBD quoi) et puis
> des snapshots soit LVM2 soit ZFS pour obtenir des instances base'es
> sur ces vdisks. C'est funky et pas pret pour la prod j'en conviens,
> mais bon dans mes PoCs pour l'instant cela marche. J'ai parle' de mes
> peurs concernant LVM2 ici:
> https://www.youtube.com/watch?v=gUnFc99VfTo&list=PLQMQQsKgvLntZiKoELFs22Mtk…
>
Ta vidéo est très intéressante et reflète mes propres recherches.
Toutefois j'ai appris des trucs aussi, merci !
La salle est très sympa mais il est choquant de voir qu'il y a si peu de
gens à t'écouter (i.e à se poser les bonnes questions, même non
conventionnelles).
J'ai la même impression concernant un langage que je promeus depuis
longtemps, Ada.
> J'ai pouss'e le vice jusqu'`a tenter la convergence re'seau en plus de
> la convergence XEN + DRBD:
> https://pub.nethence.com/network/fuck-martinez-part4
Ouah, son site, on dirait (presque) du gopher :>
En pratique ? Pour nos use cases ? mmm... Mais j'ai gardé les liens :)
>> Comme j'ai pas trouvé d'équivalent sous Linux (dans mon use-case), je
>> rêvais à me mettre à FreeBSD/ZFS qui semble avoir ce qu'il faut
>> nativement, lui. Mais, une seule vie, pas assez de temps :)
>
> ah non c'est l'inverse. FreeBSD HAST n'est probablement pas capable
> de faire du dual-primaries, ce qui est absolument ne'cessaire lors de
> la live-migration d'une instance XEN d'un noeud `a l'autre, ne
> serait-ce que pendant une micro-seconde. Je n'ai jamais essaye' HAST
> et cela reste `a faire (si un jour vous vous ennuyez, on pourrait
> faire cela ensemble en visio). Quant `a ZFS c'est juste un
> gestionnaire de volume + filesystem, pas un outils de stockage
> distribue' en soit. Ceux qui s'en servent comme cela jouent sur la
> fonction re'seau mais il n'y a qu'un seul controlleur, c'est le
> client. Un peu comme du RAID ge're' avec un seul controlleur. Avec
> DRBD et HAST c'est deux tetes, deux controlleurs. Et en plus
> duellement actif avec DRBD si besoin. De la magie pure !
Je n'ai pas été jusque là. Jamais utilisé ZFS, par manque de temps (je
suis curieux par défaut) et pragmatisme puisque Xen + GNU/Linux Debian +
mdadm + lvm2 forment une stack avec une stabilité qui s'oublie, donc pas
cherché plus loin.
Ce que je voulais faire, c'était de la migration à chaud. Dans un
process automatique, éventuellement avec une prise de décision
automatique (ce dernier point étant débattable, je me méfie comme de la
peste des "automatismes de décision" fondés sur des conditions).
Après plein d'essais, allant de magie noire (quand ça marche, c'est
beau) à la migration avortée, jusqu'à la destruction instantanée et
inexplicable du volume LVM (et... non ! je ne m'étais pas emmêlé les
scripts dans les primaires/secondaires), j'ai enfin admis que c'était
overkilled par rapport aux besoins de l'infra. Nos clients peuvent
supporter une coupure de quelques minutes (transfert de la VM, maj IPFO,
maj routage+FW du node, maj IP de l'instance - pointopoint).
Je n'ai pas pu, en boucle, faire tourner ça des dizaines de fois, sans
que ça foire à un moment, donc useless pour moi. C'était peut-être le
réseau, mais bon, le vrack OVH, ça marche. La lecture attentive des
sources de DRDB m'a un peu achevé. C'est comme regarder les sources ISDN
(RNIS/numeris) d'Asterisk (expérience d'il y a 15 ans). En regardant le
tas de spaghetti, les rustines, toussa, on soupire et on comprend mieux
pourquoi c'est chaud et pourquoi la peinture ne sera jamais sèche ; il
faudrait tout réécrire.
Rien que le bidule à base de volaile (COQ) pour aller faire correspondre
la version des sources avec la version du noyau était une horreur.
Finalement, j'allais me servir dans les dépôts Proxmox. Au moins, eux,
ils avaient la bonne réponse ;)
Mais si tu me dis que tu y es arrivé, de façon systématique et
récurrente, sans aucune erreur, dans un vrai réseau (pas un lab, en lab
ça marche), c'est que j'ai loupé une marche, ce qui est très possible :)
--
Stéphane Rivière
Ile d'Oléron - France
Bonjour
Pour janvier, nous avions fait l'impasse pour cause de début d'année et puis
l'excuse ou pas du Dry January :)
Pour février, nous ne ferons pas d'apéro non plus. La majeure partie des
habitué(e)s préfère la couette et un bonne dose de médicament en guise de
nourriture...
On se retrouvera si le voulez bien le mois prochain, en mars.
En attendant pensez à vous couvrir, rester au chaud, ...
Et toujours vaguement des infos sur :
https://keskonfai.fr/@apero_admin_sys_auvergne_rhone_alpeshttp://www.agendadulibre.org/tags/araas
Km
