[FRsAG] [JOBS] Adjoint-e au responsable informatique
Bonjour à toutes et à tous, Ma collègue ayant décidé de retourner dans son sud natal, nous cherchons un-e "adjoint-e au responsable informatique" pour bosser avec moi. Il s'agit d'une PME de transport routier comptant environ 200 salariés, dont une grosse soixantaine d'utilisateurs du SI, répartis sur 5 sites. Le poste est basé au siège, à l'est de Lyon, du côté d'Eurexpo. Des déplacements occasionnels sont à prévoir sur les autres sites, mais rien de violent. La boîte se porte plus que bien depuis sa reprise il y a 5 ans. Le service IT ne compte que deux personnes. L'intitulé du poste est volontairement vague dans la mesure où il implique de gérer absolument tout ce qui touche à l'informatique, ce qui recoupe des choses assez sympas et d'autres un peu moins. Notre infra est marquée par une forte préférence pour le libre. Beaucoup de Debian, par exemple pour gérer messagerie, serveur de fichiers, intranet, extranet, intercos openvpn lan2lan, routage (statique, avec un peu de policy routing, et je passerais bien à OSPF), QoS, parefeu, dns, dhcp, raid soft, mécanismes de haute dispo, jitsi depuis peu comme pas mal de monde, pki openssl, etc, etc. De l'OpenWRT un peu scripté dans les coins pour gérer le WiFi. L'authentification sur les principaux services réseau s'appuie sur des contrôleurs de domaine AD, via des requêtes LDAP, voire du Kerberos pour certains. Les utilisateurs bossent en bureau à distance sur une ferme RDS, depuis des machines Windows utilisées comme des client légers, à part quelques cadres dotés de laptops. Le cœur de réseau est virtualisé et tourne chez un hébergeur à forte valeur ajoutée dans un DC lyonnais, mais nous n'y intervenons pas physiquement. Il reste beaucoup à faire, dont quelques projets sympas : on a besoin d'un cluster de virtualisation on premises pour déployer des services supplémentaires non critiques (j'ai maquetté du KVM+Ganeti mais ce choix n'est pas forcément définitif - il paraît que Proxmox n'est plus allergique au RAID soft), il faut déployer IPv6, remonter un monitoring complet, aller plus loin sur le PRA/PCA, maquetter un système de clients légers en boot réseau avec freerdp, etc. L'équipe étant particulièrement réduite, il faut aussi prendre en charge des choses un peu moins marrantes à mon goût : gérer le parc matériel (mais le parc d'impression est sous contrat de maintenance+consommables), préparer les PDA android des conducteurs, assurer le support utilisateurs, mettre à jour les machines, gérer la relation avec des éditeurs de progiciels métier plus ou moins bien fichus, des problématiques propres au monde du transport (flashage codes barres, échanges EDI, étiqueteuses thermiques, sondes de température embarquées), etc. Le service IT jouit d'une grande autonomie dans son organisation et ses choix techniques. Dans l'organigramme, il se trouve directement sous la direction, qui, sans être de culture technique, percute super bien sur les questions d'IT pour peu qu'on fasse un poil de vulgarisation, et ne rechigne pas à mettre les moyens nécessaires, même si je ne pousse pas nécessairement à la dépense. Cette relation de qualité est pour moi un gros plus. Nous cherchons plutôt un profil expérimenté, mais je peux aussi former un profil junior tant que le goût de bricoler sous Linux, mais aussi de toucher à pas mal de choses différentes, est présent. Désolé, je ne vais rien pouvoir dire de plus que "rémunération selon profil", mais la maison n'est pas ingrate. Le poste est en CDI, temps plein, à pourvoir à partir de septembre. N'hésitez pas à m'envoyer une bafouille et un CV si vous voulez en savoir davantage. P.-A. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Ça marche ?
Effectivement, c'est ce que je fais aussi. Un pool de serveurs relais sortants, qui s'occupe des signatures DKIM et des règles de routage si besoin. Tous les serveurs applicatifs/infra ont un petit Postfix en local, qui fait "relayhost = relay-out.mondomaine.ext:587" et quand l'enregistrement n'est pas encadré de [], Postfix sait faire une requête MX sur le nom fourni. Ce qui donne un joli load balancers SMTP vers les relais sortants à pas cher :-) Le 07/06/2020 à 13:46, Julien Escario a écrit : Le 07/06/2020 à 11:01, Greg a écrit : Bonjour, [...] Je remettrais peut-être DKIM lors de la sortie de Mailman 2.2 ou 2.3. J'espère ne pas regretter d'avoir été transparent avec vous. Bon dimanche, Greg J'espère bien que non ! My 2 cts : on a renoncé à mettre en place les signatures DKIM sur chaque SMTP sortant, notamment parce qu'on tombe TOUJOURS sur un MTA qui ne sait pas le faire. Maintenant, on fait passer par un smarthost qui contient les clés et fait le boulot de signature avant d'envoyer le mail vers le destinataire. Ca fait un étage de plus mais beaucoup d'emmerdes en moins avec une gestion centralisée des clés. Et SMTP, c'est plutôt costaud niveau résilience/failover donc si le MTA de signature se casse la gueule, c'est facile de faire sortir par ailleurs. Julien ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retours sur galera cluster mariadb
Merci beaucoup pour ton retour. Effectivement, tu soulèves des points très importants et j'en prend note. Je t'avouerai que je suis TRES haproxy, et comme tu le disais, mon appli sait géré le R/W sur des ports différents, cela peut nous convenir. Je vais maquetter pour me faire la main sur Galera. Merci à tous pour vos retours, très intéressants et de qualités (comme d'habitude). Alex Le jeu. 25 juin 2020 à 09:15, Michel Blanc a écrit : > Le 24/06/2020 à 21:48, open doc a écrit : > > Bonjour, > > > > nous devons updater notre vieux cluster master/slaves en mariadb. On > > étudie la possibilité d'intégrer galera cluster mariadb. J'aurai aimé > > avoir quelques retours sur la techno. En êtes-vous satisfait ? il y a > > t'il des choses sur lesquels il faut absolument faire attention ? > > TL;DR: je ne mettrai du galera aujourd'hui uniquement en cas de > problèmes de performances en lecture sur un workload avec un > r/w ratio > 99% > > > C'est assez difficile de répondre sans connaître ton besoin ni les > motivations sur Galera. > > En complément des réponses précédentes: > > Galera a un mécanisme de "certification" des transactions: avant chaque > write, il va aller causer à tous les noeuds du cluster pour voir s'ils > sont d'accord pour exécuter ce write; en cas de souci ton write va > échouer; donc le RTT entre chaque noeud conditionne directement tes > performances en write (donc au final un impact majeur en perfs sur les > writes). > > Pour éviter un échec des transactions, la technique habituelle est de > write sur un seul noeud; et là, problème. Soit ton application est > intelligente et sait faire elle même le R/W splitting, soit tu dois > mettre un proxy qui parle MySQL au milieu (haproxy ne suffit pas, tu > peux effectivement faire un front end "read" et un autre "write", mais > il ne peut pas décider seul ce qui est un read et ce qui est un write). > > ProxySQL sait bien faire ça, mais ça n'est pas trivial à mettre en œuvre > correctement, notamment en cluster. Et si tu n'as qu'une instance de > loadbalancer, tu as seulement déplacé ton SPOF. > > Chez nous on posait en général un ProxySQL (pas en cluster, indépendant) > sur chaque frontal et les apps pointaient localement sur ce proxy. > > Maintenant, avec le recul (et dans notre contexte), je trouve que > l'impact en perfs de Galera et toute la machinerie annexe nécessaire > pour que ça marche bien (r/w splitting, failover, ...) vaut rarement le > coup. C'est intéressant si tu as un workload *très fortement READ* > (genre > 99%). Et même dans ce cas, c'est probablement aussi bien de > partir sur un setup primary/replica normal avec une bonne procédure de > failover et des LB au milieu. > > Par ailleurs ça nous a rarement sorti le cul des ronces en prod (plutôt > l'inverse). On a parfois pu switcher des applis sur un autre noeud à > cause d'un souci, mais on est pas sur que ce souci n'ait pas été causé > par Galera en premier lieu. > > Pour décider, tu as probablement intérêt à monter une maquette et > rejouer des slow querylogs de ton infra actuelle dessus pour voir ce que > ça donne, et te familiariser avec les procédures de recovery (bootstrap > de cluster, grastate.dat, etc...) avant de plonger dedans. > > > Bonne chance > --- > M > > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retours sur galera cluster mariadb
Merci à tous, écoutez ce que vous m'annoncer c'est très bien. Actuellement on utilise un LB (LVS oui c'est super vieux), avec 2 ports d'écoutes, un pour la lecture, un autre pour l'écriture. Globalement, le cluster 1 master, 1 candidate master et un slave. On utilise un binaire en go qui fait la migration du master vers le candidate master, il manipule les conf LVS, mariadb ..., mais par moments, la bascule ne se passe pas très bien, et le old master se retrouve avec des problèmes de synchro de slave. C'est sur cette bascule de master que je veux gagner en rapidité et en stabilité. Alex Le jeu. 25 juin 2020 à 08:26, Nicolas GIRARDI a écrit : > Bonjour, > > En effet il est conseillé d’écrire sur un seul des noeuds du cluster. > L’approche avec un HaP pour faire le R/W Splitting est une bonne solution. > > Cdlt. > > Nicolas Girardi. > > > Le 25 juin 2020 à 08:12, Michaël Couren a écrit : > > > > Bonjour, > > J'avais mis en place cette solution pour héberger des Wordpress > notamment, > > à l'époque j'avais dû passer par des bidouillages et j'avais pas mal > ramé avec Galera :) > > car le produit n'était pas encore bien mature : > > J'ai observé les mêmes problèmes de latence voire de dead-lock cités > pour des applis comme Moodle et Wordpress > > lors de multiples accès concurrentiels sur 3 nœuds actifs, peut-être > aussi dus à des problèmes en dehors du logiciel (glusterFS), mais > > j'avais dû finalement avec HAProxy en frontal diriger les requêtes sur > un noeud "principal" pour conserver le secondaire et le troisième > > en "backup" (au sens HAProxy - car pour Galera cluster ils sont tous > actifs). > > > > Maintenant il est probable qu'une implantation récente de chez Mariadb > doit mieux fonctionner, le produit évoluait souvent > > et j'ai pas opté pour une ré-installation "from scatch" depuis. > > > > -- > > Cordialement / Best regards, Michaël Couren, > > ABES, Montpellier, France. > > ___ > > Liste de diffusion du FRsAG > > http://www.frsag.org/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retours sur galera cluster mariadb
Le 25/06/2020 à 09:00, Julien - ISWT a écrit : > Est-ce qu'il existe un équivalent au MySQL Router pour Galera ou > finalement le front HAProxy est la solution la plus simple? Oui il y a https://proxysql.com/ Attention, bien que haproxy puisse faire loadbalancer TCP, il ne sait pas faire du R/W splitting MySQL (sauf développement récent que j'aurai loupé ou extension en LUA peut être ?). C'est l'application qui doit choisir vers quel front haproxy elle doit envoyer sa query. M ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retours sur galera cluster mariadb
Le 24/06/2020 à 21:48, open doc a écrit : > Bonjour, > > nous devons updater notre vieux cluster master/slaves en mariadb. On > étudie la possibilité d'intégrer galera cluster mariadb. J'aurai aimé > avoir quelques retours sur la techno. En êtes-vous satisfait ? il y a > t'il des choses sur lesquels il faut absolument faire attention ? TL;DR: je ne mettrai du galera aujourd'hui uniquement en cas de problèmes de performances en lecture sur un workload avec un r/w ratio > 99% C'est assez difficile de répondre sans connaître ton besoin ni les motivations sur Galera. En complément des réponses précédentes: Galera a un mécanisme de "certification" des transactions: avant chaque write, il va aller causer à tous les noeuds du cluster pour voir s'ils sont d'accord pour exécuter ce write; en cas de souci ton write va échouer; donc le RTT entre chaque noeud conditionne directement tes performances en write (donc au final un impact majeur en perfs sur les writes). Pour éviter un échec des transactions, la technique habituelle est de write sur un seul noeud; et là, problème. Soit ton application est intelligente et sait faire elle même le R/W splitting, soit tu dois mettre un proxy qui parle MySQL au milieu (haproxy ne suffit pas, tu peux effectivement faire un front end "read" et un autre "write", mais il ne peut pas décider seul ce qui est un read et ce qui est un write). ProxySQL sait bien faire ça, mais ça n'est pas trivial à mettre en œuvre correctement, notamment en cluster. Et si tu n'as qu'une instance de loadbalancer, tu as seulement déplacé ton SPOF. Chez nous on posait en général un ProxySQL (pas en cluster, indépendant) sur chaque frontal et les apps pointaient localement sur ce proxy. Maintenant, avec le recul (et dans notre contexte), je trouve que l'impact en perfs de Galera et toute la machinerie annexe nécessaire pour que ça marche bien (r/w splitting, failover, ...) vaut rarement le coup. C'est intéressant si tu as un workload *très fortement READ* (genre > 99%). Et même dans ce cas, c'est probablement aussi bien de partir sur un setup primary/replica normal avec une bonne procédure de failover et des LB au milieu. Par ailleurs ça nous a rarement sorti le cul des ronces en prod (plutôt l'inverse). On a parfois pu switcher des applis sur un autre noeud à cause d'un souci, mais on est pas sur que ce souci n'ait pas été causé par Galera en premier lieu. Pour décider, tu as probablement intérêt à monter une maquette et rejouer des slow querylogs de ton infra actuelle dessus pour voir ce que ça donne, et te familiariser avec les procédures de recovery (bootstrap de cluster, grastate.dat, etc...) avant de plonger dedans. Bonne chance --- M ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retours sur galera cluster mariadb
Bonjour. Le projet ProxySQL est le mieux pour cela. https://github.com/sysown/proxysql/wiki/MySQL-Server-Configuration Cdt Alexandre Le jeu. 25 juin 2020 à 09:00, Julien - ISWT a écrit : > Est-ce qu'il existe un équivalent au MySQL Router pour Galera ou > finalement le front HAProxy est la solution la plus simple? > > > Le 25/06/2020 à 08:26, Nicolas GIRARDI a écrit : > > Bonjour, > > En effet il est conseillé d’écrire sur un seul des noeuds du cluster. > L’approche avec un HaP pour faire le R/W Splitting est une bonne solution. > > Cdlt. > > Nicolas Girardi. > > > Le 25 juin 2020 à 08:12, Michaël Couren a > écrit : > > Bonjour, > J'avais mis en place cette solution pour héberger des Wordpress notamment, > à l'époque j'avais dû passer par des bidouillages et j'avais pas mal ramé > avec Galera :) > car le produit n'était pas encore bien mature : > J'ai observé les mêmes problèmes de latence voire de dead-lock cités pour des > applis comme Moodle et Wordpress > lors de multiples accès concurrentiels sur 3 nœuds actifs, peut-être aussi > dus à des problèmes en dehors du logiciel (glusterFS), mais > j'avais dû finalement avec HAProxy en frontal diriger les requêtes sur un > noeud "principal" pour conserver le secondaire et le troisième > en "backup" (au sens HAProxy - car pour Galera cluster ils sont tous actifs). > > Maintenant il est probable qu'une implantation récente de chez Mariadb doit > mieux fonctionner, le produit évoluait souvent > et j'ai pas opté pour une ré-installation "from scatch" depuis. > > -- > Cordialement / Best regards, Michaël Couren, > ABES, Montpellier, France. > ___ > Liste de diffusion du FRsAGhttp://www.frsag.org/ > > ___ > Liste de diffusion du FRsAGhttp://www.frsag.org/ > > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > -- Alexandre ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retours sur galera cluster mariadb
Est-ce qu'il existe un équivalent au MySQL Router pour Galera ou finalement le front HAProxy est la solution la plus simple? Le 25/06/2020 à 08:26, Nicolas GIRARDI a écrit : Bonjour, En effet il est conseillé d’écrire sur un seul des noeuds du cluster. L’approche avec un HaP pour faire le R/W Splitting est une bonne solution. Cdlt. Nicolas Girardi. Le 25 juin 2020 à 08:12, Michaël Couren a écrit : Bonjour, J'avais mis en place cette solution pour héberger des Wordpress notamment, à l'époque j'avais dû passer par des bidouillages et j'avais pas mal ramé avec Galera :) car le produit n'était pas encore bien mature : J'ai observé les mêmes problèmes de latence voire de dead-lock cités pour des applis comme Moodle et Wordpress lors de multiples accès concurrentiels sur 3 nœuds actifs, peut-être aussi dus à des problèmes en dehors du logiciel (glusterFS), mais j'avais dû finalement avec HAProxy en frontal diriger les requêtes sur un noeud "principal" pour conserver le secondaire et le troisième en "backup" (au sens HAProxy - car pour Galera cluster ils sont tous actifs). Maintenant il est probable qu'une implantation récente de chez Mariadb doit mieux fonctionner, le produit évoluait souvent et j'ai pas opté pour une ré-installation "from scatch" depuis. -- Cordialement / Best regards, Michaël Couren, ABES, Montpellier, France. ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retours sur galera cluster mariadb
Bonjour, En effet il est conseillé d’écrire sur un seul des noeuds du cluster. L’approche avec un HaP pour faire le R/W Splitting est une bonne solution. Cdlt. Nicolas Girardi. > Le 25 juin 2020 à 08:12, Michaël Couren a écrit : > > Bonjour, > J'avais mis en place cette solution pour héberger des Wordpress notamment, > à l'époque j'avais dû passer par des bidouillages et j'avais pas mal ramé > avec Galera :) > car le produit n'était pas encore bien mature : > J'ai observé les mêmes problèmes de latence voire de dead-lock cités pour des > applis comme Moodle et Wordpress > lors de multiples accès concurrentiels sur 3 nœuds actifs, peut-être aussi > dus à des problèmes en dehors du logiciel (glusterFS), mais > j'avais dû finalement avec HAProxy en frontal diriger les requêtes sur un > noeud "principal" pour conserver le secondaire et le troisième > en "backup" (au sens HAProxy - car pour Galera cluster ils sont tous actifs). > > Maintenant il est probable qu'une implantation récente de chez Mariadb doit > mieux fonctionner, le produit évoluait souvent > et j'ai pas opté pour une ré-installation "from scatch" depuis. > > -- > Cordialement / Best regards, Michaël Couren, > ABES, Montpellier, France. > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retours sur galera cluster mariadb
Bonjour, J'avais mis en place cette solution pour héberger des Wordpress notamment, à l'époque j'avais dû passer par des bidouillages et j'avais pas mal ramé avec Galera :) car le produit n'était pas encore bien mature : J'ai observé les mêmes problèmes de latence voire de dead-lock cités pour des applis comme Moodle et Wordpress lors de multiples accès concurrentiels sur 3 nœuds actifs, peut-être aussi dus à des problèmes en dehors du logiciel (glusterFS), mais j'avais dû finalement avec HAProxy en frontal diriger les requêtes sur un noeud "principal" pour conserver le secondaire et le troisième en "backup" (au sens HAProxy - car pour Galera cluster ils sont tous actifs). Maintenant il est probable qu'une implantation récente de chez Mariadb doit mieux fonctionner, le produit évoluait souvent et j'ai pas opté pour une ré-installation "from scatch" depuis. -- Cordialement / Best regards, Michaël Couren, ABES, Montpellier, France. ___ Liste de diffusion du FRsAG http://www.frsag.org/
