[FRsAG] [JOBS] Administrateur systèmes et réseaux Linux/Windows
Bonjour. Le groupe Webedia (Allociné, Purepeople, 750g, Jeuxvidéo.com, CanalBlog, etc) recherche un Administrateur Système pour la partie Allociné. Voici l'offre : Contexte : Le groupe Webedia (Allociné, Purepeople, 750g, Jeuxvidéo.com, CanalBlog, etc), groupe de média numérique en pleine croissance, recherche un Administrateur systèmes et réseaux. Dans le cadre de notre croissance, nous recherchons un administrateur systèmes et réseaux qui intervient sur des architecture internet complexes, critiques et de hautes disponibilités. Vous travaillerez au sein du pôle technique et de l’équipe administration systèmes et réseaux et en relations étroites avec les équipes de développement, avec une responsabilité spécifique sur le site Allociné en France et à l’international. Description des missions : Vous serez principalement en charge de : Référent pour l’architecture technique web Allociné Superviser et administrer quotidiennement les serveurs et intervenir sur nos différentes infrastructures internet et datacenters Installer, optimiser et faire évoluer ses éléments matériels et logiciels Etre source de proposition de nouvelles solutions techniques adaptées Piloter et mettre en œuvre les évolutions décidées Rédiger de la documentation Travailler en collaboration avec l’équipe administration systèmes et réseau, les équipes de développement et les prestataires hébergements Assurer le lien avec les équipes internes et externes Rapporter à votre manager Participation à la définition de la stratégie d'évolution et à la mise en oeuvre de ces évolutions (Plan de Continuité d’Activité, optimisations, etc.) Compte-tenu de la croissance du groupe, vos missions sont évolutives dans le temps selon votre motivation et capacité à gérer les tâches qui vous seront confiées. Profil : Formation supérieure en informatique avec expérience de 3 à 5 ans dans un poste similaire. Compétences techniques requises : Maitrise de l’environnement Linux (Debian, Ubuntu) et de logiciels associés (LAMP, Nginx, LVS, HaProxy, Varnish, langage de script). Connaissances en environnement Microsoft (Windows server, IIS, Active directory, ACL NTFS/GPO). Environnement de virtualisation VmWare ESX. NAS/SAN/DFS et autres technologies de stockage. Connaissance des architectures réseaux web, des protocoles réseaux (TCP/IP, Ethernet). Compétences techniques qui seraient un plus : Services tiers AWS. Gestionnaire de configuration Puppet. Matériels et logiciels réseaux (Cisco / Brocade / Juniper). Layer 7 HTTP. Outils de monitoring Cacti et Nagios. Qualités requises : Rigueur et organisation. Disponibilité et réactivité. Etre curieux et résister au stress. Aptitude à travailler en équipe. Savoir rédiger de la documentation claire (procédures, dossiers d’architectures, etc.). Pour l'instant, le poste est à pourvoir dans le 8ème arrondissement de Paris. Cependant, un déménagement à Levallois est prévu pour le second trimestre 2015. Pour le salaire, il faut compter une fourchette entre 40k€ et 50k€ brut annuel. Envoyez moi vos candidatures en direct. Merci. -- Cyril Davromaniak Lavier KeyID 59E9A881 http://www.davromaniak.eu ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Galera Cluster
Bonjour la liste, sur le papier, Galera Cluster semble parfait pour remplacer un ensemble de master-slaves sans avoir les coûts d'un NDB. En pratique, sur une maquette avec des vrais serveurs physiques et des vrais données venant de la prod, je me prends des segfault, des arrêts brutaux de mysqld, et une resynchro plutot aléatoire ... alors que cette solution est vendue pour améliorer la haute-dispo. Alors j'aimerais avoir des retours d'expériences, savoir si ça vaut le coup que j'investisse encore du temps ou si elle est encore clairement immature pour de la prod. Sachant qu'un cluster Galera coûte plus cher en terme de ressources dans certains cas, parce qu'il faut minimum 3 serveurs ce qui n'est pas le cas pour une partie de mon archi qui ne comprend qu'un master + un slave. Aussi, avec l'arrivée des GTIDs, élire un slave master et reconfigurer les slaves devient très simple: STOP SLAVE; CHANGE MASTER TO MASTER_HOST=new_master; START SLAVE; Avez vous des retours en conditions réels ? -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Galera Cluster
Bonjour, Quelle est la version de Galera Cluster utilisée ? MySQL (5.5 ou 5.6) ? Ou MariaDB (5.5 ou 10) ? Jocelyn Le 28/11/2014 09:31, Greg a écrit : Bonjour la liste, sur le papier, Galera Cluster semble parfait pour remplacer un ensemble de master-slaves sans avoir les coûts d'un NDB. En pratique, sur une maquette avec des vrais serveurs physiques et des vrais données venant de la prod, je me prends des segfault, des arrêts brutaux de mysqld, et une resynchro plutot aléatoire ... alors que cette solution est vendue pour améliorer la haute-dispo. Alors j'aimerais avoir des retours d'expériences, savoir si ça vaut le coup que j'investisse encore du temps ou si elle est encore clairement immature pour de la prod. Sachant qu'un cluster Galera coûte plus cher en terme de ressources dans certains cas, parce qu'il faut minimum 3 serveurs ce qui n'est pas le cas pour une partie de mon archi qui ne comprend qu'un master + un slave. Aussi, avec l'arrivée des GTIDs, élire un slave master et reconfigurer les slaves devient très simple: STOP SLAVE; CHANGE MASTER TO MASTER_HOST=new_master; START SLAVE; Avez vous des retours en conditions réels ? -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retour d'expérience: panne du DC Level3
tu ne fais qu'aborder un truc commun en sécurité informatique, et quand je parle de sécurité informatique, je l'entend au niveau de la théorie de la sécurité. On se dit toujours que celà ne nous arriveras jamais = conclusion ça nous arrive et on est pas prêt. Si la disponibilité est très importante il faut investir en conséquence, il faut le faire comprendre aux décideur, et c'est là tout le soucis Cordialement Alexis Lameire Le 28 novembre 2014 10:10, Greg greg-fr...@duchatelet.net a écrit : Bonjour, Je n'ai pas encore reçu de RFO sur cette panne électrique donc je ne donnerai pas de détails sur ce qui s'est passé. C'est la 2ème panne majeure sur ce DC en 14 mois: en octobre 2013 c'est la clim qui avait arrêtée de fonctionner... Petite récap des conséquences physiques : - 2 PDU APC ont cramé - l'ensemble de mes équipements a redémarré au moins une fois - une bonne dizaine de serveurs ont redémarrés électriquement et aucun d'entre eux n'a causé de problèmes - un voisin, je ne sais pas qui, a perdu 12 serveurs qui ne redémarreront jamais ... Au final, j'aurais perdu peu de matériel, et heureusement parce que je n'avais pas assez de spares. Ce n'est pas ma première panne datacenter, mais c'est aussi dans ce cas qu'on peut juger de la qualité des constructeurs : - Serveurs Dell, rien à dire à partir des R320. Les vieux 1950 et 2950 tiennent toujours la route comme au début. La gamme des R200 est insuffisante en terme de qualité physique. - Brocade : il faut du haut de gamme. Le milieu de gamme ne tient pas les montées de température. Par exemple, mes vieux FESX de 8 ans sont monté à 105° et fonctionnent toujours contrairement aux FCX de 3 ans qui ont tous arrêter de fonctionner. Mais un FESX coute le double d'un FCX ... - APC : c'est sensé être du haut de gamme et pourtant ... ils sont trop sensible à la température et arrêtent de fonctionner les un après les autres, à la moindre hausse de T° ... (Je n'ai que du switched) - KVM Dell (en réalité du Advocent) : RAS. Maintenant au niveau business : - on a perdu 3h d'activité, perte sèche de CA - l'activité est revenue complètement à la normale en ~8h Ce qui ramène aux conclusions stratégiques et managériales : - on est en plein dans le nobody known what I do until I don't do it, du coup quand tout fonctionne l'équipe ops se retrouve à faire de plus en plus autre chose que son métier, comme du développement - les Ops sont tout de même responsables car ... c'est dans leur responsabilité - les économies faites sur le matériel coûtent finalement bien plus cher ... Tout ça ce sont des évidences auxquelles nous avons été et nous sommes confrontés régulièrement. Cette panne m'aura fait prendre quelques cheveux blancs supplémentaires, et m'aura donné l'occasion de croiser le regard déçu de mon patron ... mais aussi de redéfinir les priorités. Même quand tout fonctionne, les sysadmin doivent faire évoluer une archi, et pas que pour des raisons de sécu ou de perfs. Donc la question du trolldi est: est-ce qu'il est nécessaire d'avoir de temps en temps une grosse panne à gérer ? C'est paradoxale ... Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Galera Cluster
Bonjour. En pratique, sur une maquette avec des vrais serveurs physiques et des vrais données venant de la prod, je me prends des segfault, des arrêts brutaux de mysqld, et une resynchro plutot aléatoire ... alors que cette solution est vendue pour améliorer la haute-dispo. Lorsque je l'avais test, et il y a déjà un moment dans MariaDB, je n'ai pas remarque de segfault. Peux tu effectivement nous en dire plus sur les versions que tu utilises, et aussi ce que tu as téléchargé, sur quel OS, etc ... ? Cdlt ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Galera Cluster
Je ne souhaite pas préciser les versions pour ne pas rentrer dans un débat oui mais avec telle version de Percona ça marche par contre du coup tu n'auras pas la feature X de MariaDB etc ... Ce qui m'intéresse c'est un retour d'expérience en production. Le 28 novembre 2014 10:36, Alexandre Legrix a...@bragonux.net a écrit : Bonjour. En pratique, sur une maquette avec des vrais serveurs physiques et des vrais données venant de la prod, je me prends des segfault, des arrêts brutaux de mysqld, et une resynchro plutot aléatoire ... alors que cette solution est vendue pour améliorer la haute-dispo. Lorsque je l'avais test, et il y a déjà un moment dans MariaDB, je n'ai pas remarque de segfault. Peux tu effectivement nous en dire plus sur les versions que tu utilises, et aussi ce que tu as téléchargé, sur quel OS, etc ... ? Cdlt -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Galera Cluster
On 11/28/14 10:44, Greg wrote: Je ne souhaite pas préciser les versions pour ne pas rentrer dans un débat oui mais avec telle version de Percona ça marche par contre du coup tu n'auras pas la feature X de MariaDB etc ... Ce qui m'intéresse c'est un retour d'expérience en production. Ok alors sans entrer dans un debat de clocher puisque tu ne veux pas parler de version ... (Chose que je trouve débile, soit dit en passant) Sur des Gentoo (et/ou Debian) (Je ne dis pas la version) configurées aux petits oignons, avec des MariaDB (sans dire la version) Galera (pas de version du patch) dernière version de l’époque (mais je dis pas la date) (puisqu'on ne doit pas parler de version ) , ça marchait en production sans segfault ! avec un datadir d'environ 20Gb Tu vois a quel point c'est ridicule de ne pas vouloir donner de versions ? /fin ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Galera Cluster
Voici un retour d'expérience en prod que j'ai interrogé le mois dernier http://alx-communication.over-blog.com/article-le-fournisseur-d-acces-a-internet-enter-a-fait-le-choix-de-galera-cluster-124922938.html Il te manquera sans doute des précisions techniques, mais au cas où je peux faire remonter tes questions à Codership Véro Le 28/11/2014 09:31, Greg a écrit : Bonjour la liste, sur le papier, Galera Cluster semble parfait pour remplacer un ensemble de master-slaves sans avoir les coûts d'un NDB. En pratique, sur une maquette avec des vrais serveurs physiques et des vrais données venant de la prod, je me prends des segfault, des arrêts brutaux de mysqld, et une resynchro plutot aléatoire ... alors que cette solution est vendue pour améliorer la haute-dispo. Alors j'aimerais avoir des retours d'expériences, savoir si ça vaut le coup que j'investisse encore du temps ou si elle est encore clairement immature pour de la prod. Sachant qu'un cluster Galera coûte plus cher en terme de ressources dans certains cas, parce qu'il faut minimum 3 serveurs ce qui n'est pas le cas pour une partie de mon archi qui ne comprend qu'un master + un slave. Aussi, avec l'arrivée des GTIDs, élire un slave master et reconfigurer les slaves devient très simple: STOP SLAVE; CHANGE MASTER TO MASTER_HOST=new_master; START SLAVE; Avez vous des retours en conditions réels ? -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/ --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Galera Cluster
Bonjour. J'ai mis en prod un cluster Percona XtraDB (donc Galera) de 5 noeuds. Franchement, je n'en suis pas déçu, ça marche très bien. Un point négatif, c'est la répartition de charge, j'ai mis le cluster derrière un BigIP, et au niveau des écritures, j'ai dû créer un pool à part en mode actif/passif, avec un noeud actif pour les écritures, sans ça, j'avais une trouzaine de deadlocks dans tous les sens, et même avec des modifications de code, de requêtes SQL ou de schémas, il m'en restait. En passant sur le pool avec un noeud actif en écriture, je dois avoir 1 ou 2 deadlocks dans la journée, ce qui est bien mieux qu'avant. Pour la stabilité, les seuls incidents étaient causés par des pebkacs, avec une désynchro de tous les noeuds et donc le cluster qui tombe. J'ai déjà une machine du cluster qui a grillée, et à part quelques alertes de supervision, et un cluster légèrement plus lent, je n'ai eu aucun impact en production. J'espère que ça va t'aider. Merci. From: Greg greg-fr...@duchatelet.net To: French SysAdmin Group frsag@frsag.org Sent: Friday, 28 November, 2014 10:44:22 Subject: Re: [FRsAG] Galera Cluster Je ne souhaite pas préciser les versions pour ne pas rentrer dans un débat oui mais avec telle version de Percona ça marche par contre du coup tu n'auras pas la feature X de MariaDB etc ... Ce qui m'intéresse c'est un retour d'expérience en production. Le 28 novembre 2014 10:36, Alexandre Legrix a...@bragonux.net a écrit : Bonjour. BQ_BEGIN BQ_BEGIN En pratique, sur une maquette avec des vrais serveurs physiques et des vrais données venant de la prod, je me prends des segfault, des arrêts brutaux de mysqld, et une resynchro plutot aléatoire ... alors que cette solution est vendue pour améliorer la haute-dispo. BQ_END Lorsque je l'avais test, et il y a déjà un moment dans MariaDB, je n'ai pas remarque de segfault. Peux tu effectivement nous en dire plus sur les versions que tu utilises, et aussi ce que tu as téléchargé, sur quel OS, etc ... ? Cdlt BQ_END -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/ -- Cyril Davromaniak Lavier KeyID 59E9A881 http://www.davromaniak.eu ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retour d'expérience: panne du DC Level3
Hello Greg, Petite récap des conséquences physiques : - 2 PDU APC ont cramé - l'ensemble de mes équipements a redémarré au moins une fois - une bonne dizaine de serveurs ont redémarrés électriquement et aucun d'entre eux n'a causé de problèmes - un voisin, je ne sais pas qui, a perdu 12 serveurs qui ne redémarreront jamais ... Sympa, tu as de la chance car ton voisin n'en as pas eu. Le fait que des APC ont cramé c'est soit qu'il y a eu un retour de courant important, soit qu'ils étaient trop vieux. Au final, j'aurais perdu peu de matériel, et heureusement parce que je n'avais pas assez de spares. Ce n'est pas ma première panne datacenter, mais c'est aussi dans ce cas qu'on peut juger de la qualité des constructeurs : - Serveurs Dell, rien à dire à partir des R320. Les vieux 1950 et 2950 tiennent toujours la route comme au début. La gamme des R200 est insuffisante en terme de qualité physique. - Brocade : il faut du haut de gamme. Le milieu de gamme ne tient pas les montées de température. Par exemple, mes vieux FESX de 8 ans sont monté à 105° et fonctionnent toujours contrairement aux FCX de 3 ans qui ont tous arrêter de fonctionner. Mais un FESX coute le double d'un FCX ... Ils ont fait des efforts, j'ai eu des ServerIron XL qui ont arrêté de fonctionner a 62°C (le switch fonctionnais a peu près, mais le LB L7 - mort). Ceci dit, si tu regardes les datasheets de Brocade ils sont clair au dessus de 55°C : c'est plus dans les specs, conclusion il faut des fois bien ranger ses baies. - APC : c'est sensé être du haut de gamme et pourtant ... ils sont trop sensible à la température et arrêtent de fonctionner les un après les autres, à la moindre hausse de T° ... (Je n'ai que du switched) Idem, 55°C dans une baie, c'est que tu as un pb. - KVM Dell (en réalité du Advocent) : RAS. Maintenant au niveau business : - on a perdu 3h d'activité, perte sèche de CA - l'activité est revenue complètement à la normale en ~8h Ce qui ramène aux conclusions stratégiques et managériales : - on est en plein dans le nobody known what I do until I don't do it, du coup quand tout fonctionne l'équipe ops se retrouve à faire de plus en plus autre chose que son métier, comme du développement - les Ops sont tout de même responsables car ... c'est dans leur responsabilité - les économies faites sur le matériel coûtent finalement bien plus cher ... Effectivement, et je dirais même plus : les économies faites quand on est dans un seul datacenter sont des fois, dans des cas où les clients sont sur l'internet, des fausses économies. Vaux mieux avoir un systèmes redondonant sur 2 DC quittes a avoir a tenir une charge moindre que faire de la perte de CA. D'ailleurs vu que tu as 3h de pertes sèche de CA, tu peux donc calculer combien d'argent a été perdue et donc calculer si avoir un second DC serait une bonne idée. A ajouter dans ce cas : être maitre de son routage. Ca aide beaucoup pour faire des choses fiables. Donc la question du trolldi est: est-ce qu'il est nécessaire d'avoir de temps en temps une grosse panne à gérer ? C'est paradoxale ... Mon expérience avec nos amis les DAF, il faut souvent qu'ils se trouvent au pied du mur pour qu'ils agissent, et en général n'écoutent jamais les responsables / sysadmin senior / guru qui leur disent : si on fait pas ça on vas se payer un mur. Dans la boite où je suis, à chaque fois qu'ils se payent un mur ils font ce que je leur avais dit plusieurs mois ou années avant, comme par ex : - changer / entretenir la clim du DC au bureau - bouger les serveurs sensible dans un vrai DC (avec onduleurs / groupe et double clim) - virer colt (désolé s'il y a des gens de colt içi) et prendre un opérateur qui facture pas 1K€ une connectivité a 10Mbps par mois - dégager les tunnel IPSEC + ADSL boxalacon et coller des SDSL - tuer les serveurs legacy asap (qui datent de 2003 et qui sont pas à jour) et migrer sur des solutions opensource/logicielles qui peuvent être maintenues - avoir du spare de switch... - le backup ... :) En deux ans, chaque point évoqués ont bougés quand ils se sont payés un mur, malgré les informations claires et précises du mur qui arrive demain... Je ne sais pas si c'est un standard des entreprises francaises, mais hélas c'est quelque chose que je vois (et pas que moi) de plus en plus souvent dans la gestion des risques informatiques. Souvent l'informatique est prise comme un outil et les DAF sont incapables de comprendre pourquoi on demande une enveloppe de 20K€ pour sécuriser un truc qui marche déjà bien comme ça... /trolldi Xavier signature.asc Description: Message signed with OpenPGP using GPGMail ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retour d'expérience: panne du DC Level3
Salut Grégory, Les incidents en datacentre arrivent, j'aurais tendance à dire qu'ils arrivent à présent moins souvent avec les derniers modèles de design 2N voir plus mais comme ces datacentres sont tout neuf et qu'ils n'ont pas encore essuyé les plâtres il faudra attendre pour voir arriver les premiers problèmes. Concernant le matériel je te rejoins sans soucis, il y a presque 10 ans nous avons eu dans un datacentre privé une grosse panne de clim en plein été caniculaire. Nous avons eu beau mettre des blocs de clim mobiles louées, des ventilos de pompiers la chaleur était intenable humainement et pourtant lorsqu'on a craint un départ d'incendie tellement les serveurs et rack étaient brulant on nous a dit noway. Pourtant ce risque était sérieux mais ça a tenu, 10h sans clim et les serveurs qui étaient en vie à la fin c'était tous les IBM et HP UX attention je parle des monstres d'y il y a 10 ans donc 4U mini et donc pas mal de place à l'intérieur pour un gros dissipateur thermique. Ce qui n'avait pas résisté à l'époque c'était tous les serveurs entrée / moyen de gamme y compris chez les constructeurs sérieux. Mais bon passer 10h dans une pièce à 70° au niveau de l'air et sans doute dépasser la centaine en interne sur les cpu / disque ce n'est pas donné à tout matériel. Encore plus en arrière y a 14 ans pour un opérateur vert de l'époque, nous avions une salle à CBV Ldcom où nous avions demandé à avoir du 14° en température sortie de grille au sol pour qu'en haut des racks on ne dépasse pas les 19° à l'entrée des serveurs. Pourquoi? Parce que c'était que des serveurs low cost et si ils dépassaient les 25° en entrée des serveurs on perdait des composants aléatoirement. Mais par contre on avait pour 200 serveurs en pièce détachée l'équivalent d'une quinzaine. Quand on rackait on avait tellement froid qu'on allai se réchauffer derrière les serveurs Prost Grand Prix qui chauffaient fort, souvenirs :D Après pour parler revenues, si une activité ne peut supporter quelques heures de coupures c'est qu'il est temps en effet de rallonger le budget pour mettre une redondance en place sur 2 DC et faire le développement nécessaire pour que les applications suivent. Ou alors faire comme un client il y a 10 ans où Google était tombé en panne un dimanche après midi pendant 5h soit on accédait pas à leurs sites, soit les résultats renvoyés étaient loufoques. Le client dépendait tellement du référencement que plus de 90% de ses visites ont disparus pendant ce temps. Le manque a gagné en pub était autour de 25K€. Le lendemain ils s'assuraient en perte de CA ce qui leur a coûté 10% de leur CA annuel. Je sais pas si avec le recul et la chute des revenus publicitaires cela leur a servi à nouveau mais c'est aussi une solution pour lisser la perte sans trop sortir de moyens techniques. Et pour ta question, oui une architecture ça s'entretient, si tu passes sur autre chose en interne c'est que l'infra n'est pas critique ou alors qu'il est temps de sous traiter la gestion quotidienne en infogérance. ++ signature.asc Description: OpenPGP digital signature ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retour d'expérience: panne du DC Level3
Salut Xavier, Le 28 novembre 2014 10:58, Xavier Beaudouin k...@oav.net a écrit : Sympa, tu as de la chance car ton voisin n'en as pas eu. Le fait que des APC ont cramé c'est soit qu'il y a eu un retour de courant important, soit qu'ils étaient trop vieux. voir plus bas ;) Idem, 55°C dans une baie, c'est que tu as un pb. c'est lors de la panne de clim d'octobre 2013 que la température a monté drastiquement. Suite à quoi j'ai perdu les FCX et PDU un par un sur 14 mois donc ... Effectivement, et je dirais même plus : les économies faites quand on est dans un seul datacenter sont des fois, dans des cas où les clients sont sur l'internet, des fausses économies. Vaux mieux avoir un systèmes redondonant sur 2 DC quittes a avoir a tenir une charge moindre que faire de la perte de CA. on est déjà sur 2 sites, mais on m'a coupé les vivres en route suite à un changement de DG, je n'ai donc pas pu finir le travail ... D'ailleurs vu que tu as 3h de pertes sèche de CA, tu peux donc calculer combien d'argent a été perdue et donc calculer si avoir un second DC serait une bonne idée. Clairement, 3H de perte sèche de CA ne représente pas ce que coûterait un 2eme DC (avec liens redondés etc) par contre si on ajoute les coûts des conséquences sur l'image, les partenaires etc ... ça n'a (presque) pas de prix ! A ajouter dans ce cas : être maitre de son routage. Ca aide beaucoup pour faire des choses fiables. C'était prévu en 2014 puis abandonné pour les mêmes raisons. Mais c'est cool, je vais pouvoir relancer ce projet aussi :) Mon expérience avec nos amis les DAF, il faut souvent qu'ils se trouvent au pied du mur pour qu'ils agissent, et en général n'écoutent jamais les responsables / sysadmin senior / guru qui leur disent : si on fait pas ça on vas se payer un mur. Dans la boite où je suis, à chaque fois qu'ils se payent un mur ils font ce que je leur avais dit plusieurs mois ou années avant, comme par ex : - changer / entretenir la clim du DC au bureau - bouger les serveurs sensible dans un vrai DC (avec onduleurs / groupe et double clim) - virer colt (désolé s'il y a des gens de colt içi) et prendre un opérateur qui facture pas 1K€ une connectivité a 10Mbps par mois - dégager les tunnel IPSEC + ADSL boxalacon et coller des SDSL - tuer les serveurs legacy asap (qui datent de 2003 et qui sont pas à jour) et migrer sur des solutions opensource/logicielles qui peuvent être maintenues - avoir du spare de switch... - le backup ... :) En deux ans, chaque point évoqués ont bougés quand ils se sont payés un mur, malgré les informations claires et précises du mur qui arrive demain... Même expérience, à chaque fois qu'on s'est payé le mur les choses ont évoluées. Aujourd'hui mon patron est tellement sensibilisé aux backups que c'est quasiment la 1ère chose qu'il me demande en cas de nouveau projet, et qu'on a des backups sur 4 sites :) Suite à une panne de load-balancers sur des R200, j'ai pu m'équiper de ServerIron 4G (8x plus cher) qui encaisse toutes les pannes. Suite à une autre panne pour des filers sous-dimensionnés, j'ai pu m'équiper de SAN EqualLogic (6x plus cher). On n'a plus aucun problèmes et ce sont ces systèmes qui redeviennent UP les premiers, sans corruption de données, bref sans aucune intervention ... Parce que dans le cas de solutions, je n'ai plus le droit à l'erreur, je dois m'équiper de matériel de bien meilleure qualité que ce que j'avais préconisé avant la panne. Et donc plus couteux, là encore paradoxal ... Je ne sais pas si c'est un standard des entreprises francaises, mais hélas c'est quelque chose que je vois (et pas que moi) de plus en plus souvent dans la gestion des risques informatiques. Souvent l'informatique est prise comme un outil et les DAF sont incapables de comprendre pourquoi on demande une enveloppe de 20K€ pour sécuriser un truc qui marche déjà bien comme ça... Parce qu'on demande aux DAF de faire des économies et que c'est un moyen simple d'y parvenir à court terme :-( -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retour d'expérience: panne du DC Level3
On 11/28/14 11:14, Greg wrote: En deux ans, chaque point évoqués ont bougés quand ils se sont payés un mur, malgré les informations claires et précises du mur qui arrive demain... Ce qui est navrant dans notre métier, c'est que tu dis toujours : Je vous l'avais bien dit les gars Reprenez l'email du x ou je vous expose clairement qu'il faut deux DC et/ou gérer notre réseau Je vous ai fait toute l’étude financière de bout en bout (avec 3 scenarii) , vous avez prit la décision de ne pas donner suite Mais quand arrive la panne, Et, le fait qu'il faut gérer les 3-8 au pied levés d'une heure a l'autre, parce que l’intégralité d'une production est HS, C'est quand même nous qui agissons. On a beau avoir prévenu du mur, deux, trois fois, il faut qu'on se le prenne pour que les DAF bougent. Moi je vous le dis, On ne fait pas un métier facile ;-) ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retour d'expérience: panne du DC Level3
Le 28/11/2014 11:22, Alexandre Legrix a écrit : Ce qui est navrant dans notre métier, c'est que tu dis toujours : Je vous l'avais bien dit les gars Reprenez l'email du x ou je vous expose clairement qu'il faut deux DC et/ou gérer notre réseau Je vous ai fait toute l’étude financière de bout en bout (avec 3 scenarii) , vous avez prit la décision de ne pas donner suite Mais quand arrive la panne, Et, le fait qu'il faut gérer les 3-8 au pied levés d'une heure a l'autre, parce que l’intégralité d'une production est HS, C'est quand même nous qui agissons. On a beau avoir prévenu du mur, deux, trois fois, il faut qu'on se le prenne pour que les DAF bougent. Moi je vous le dis, On ne fait pas un métier facile ;-) Quand tu démontres que les économies d'un DAF font perdre plus de CA ou d'image de marque que l'économie réalisée ça fait aussi très mal pour eux, en tout cas quand je fais de l'audit / conseils je me gêne pas pour faire remarquer que les économies de pacotilles ont été et sont donc responsable ou vont être responsable d'une grosse perte. Déjà assisté à cela en réunion de présentation d'un audit, le DAF s'est fait retourné par la direction qui était heureusement technique et pas commerciale et le CTO s'est aussi fait réprimandé, on lui a reproché de pas s'être plus justifié sur ses besoins de budget et de ne pas avoir alerté la direction quand on le DAF lui a coupé les fonds. Mais malheureusement dans la trop grande majorité des entreprises la direction est commerciale donc le DAF a plein pouvoir pour faire des économies et quand ils sont dans le mur et que l'image en prend un coup ils transforment cela en plan d'attaque de modernisation, donc grosse comm auprès des clients / partenaires et du coup ça rassure ... du coup le marketing a du taf et tout le monde est content. Limites certains ont le droit à des couvertures médias pour annoncer qu'ils ont redondés leurs infras, regardez c'est devenu critique on fait du coup ce qu'il y a de mieux ... signature.asc Description: OpenPGP digital signature ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retour d'expérience: panne du DC Level3
Moi je vous le dis, On ne fait pas un métier facile ;-) Avec de l'expérience j'ai associé les métier opérationnels de l’informatique (système/réseaux/logiciels) à de la gestion de risques. En gros il faut se forcer à faire une étude de cout/impact en cas de fail sur l'architecture dont tu as la responsabilité. Après tu présentes cela à ta direction qui fait le choix. De ton point de vue tu as fait ton boulot, même si il y a évidement plein de trucs que tu peux faire pour 0 qui vont améliorer la résilience. Et on ne pourra rien te reprocher. Maintenant c'est assez pénible de se heurter à un mur humain, je confirme :) Cdt, -- Raphael Mazelier ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retour d'expérience: panne du DC Level3
Le 28 novembre 2014 11:34, Wallace wall...@morkitu.org a écrit : Quand tu démontres que les économies d'un DAF font perdre plus de CA ou Ah c'est une bonne idée ça, économiser un DAF ! Ca coute quoi un DAF ? Aller, environ 100k€ brut soit ~ 160k€, de quoi monter une belle infra redondée et il en resterait encore ! quoi on est trolldi, non ? :) -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retour d'expérience: panne du DC Level3
Le 28/11/2014 10:10, Greg a écrit : Ce qui ramène aux conclusions stratégiques et managériales : - on est en plein dans le nobody known what I do until I don't do it, du coup quand tout fonctionne l'équipe ops se retrouve à faire de plus en plus autre chose que son métier, comme du développement - les Ops sont tout de même responsables car ... c'est dans leur responsabilité - les économies faites sur le matériel coûtent finalement bien plus cher ... Perso, je vois aussi que, avec ma petite salle climatisée qui doit ressembler à du bricolage par rapport à un datacenter renommé, je ne fais pas moins bien :-) -- Manu Jacquet ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retour d'expérience: panne du DC Level3
On 11/28/14 12:43, Manu wrote: Perso, je vois aussi que, avec ma petite salle climatisée qui doit ressembler à du bricolage par rapport à un datacenter renommé, je ne fais pas moins bien Jusqu'a la prochaine panne majeur d'EDF dans ta région avec aucune idée du quand ça va revenir ;-) Ou la prochaine canicule. On en reparle si tu le veux bien. Cdlt ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retour d'expérience: panne du DC Level3
Hello, Le 28/11/14 12:43, Manu a écrit : Le 28/11/2014 10:10, Greg a écrit : Ce qui ramène aux conclusions stratégiques et managériales : - on est en plein dans le nobody known what I do until I don't do it, du coup quand tout fonctionne l'équipe ops se retrouve à faire de plus en plus autre chose que son métier, comme du développement - les Ops sont tout de même responsables car ... c'est dans leur responsabilité - les économies faites sur le matériel coûtent finalement bien plus cher ... Perso, je vois aussi que, avec ma petite salle climatisée qui doit ressembler à du bricolage par rapport à un datacenter renommé, je ne fais pas moins bien :-) C'est toujours facile de prendre ce genre de raccourci. On est dans un métier où on fait de la gestion de risque, c'est tout le côté délicat, tant que ça fonctionne, ça parait être la bonne solution, jusqu'au jour où... Le site de Level 3 Gateway à Nanterre est un très beau site au départ, mais c'est un site historique opérateur qui accuse à la fois son âge et le fait de ne pas être un DC opéré par une société dont c'est le métier premier. Il date d'avant la crise de 2000, il a été prévu et provisionné pour complètement dès son ouverture (capa électrique, clims, salles, baies, même le câblage des baies en cuivre). Les problème qui en découlent : - Le site a 14 ans et n'a pas franchement connu beaucoup de rénovations techniques (à moins que dernièrement ça ait changé) - Le site est dans l'enceinte d'un building de bureaux dont Level 3 est locataire au RDC, ce qui entraine de contraintes - Je pense que le programme de maintenance et l'entretien sur le long terme n'est pas aussi soigné que pour d'autres DC dont c'est le métier premier - Pas de présence 24/24 de quelqu'un sur site (plus depuis qu'AOL n'est plus là) - Comme tout a été provisionné dès le lancement, l'ensemble du matériel est âgé Avec des conséquences qu'on a connu : - Rupture de canalisation des WC du 1er qui a innondé le DC il y a quelques années (problème qu'ils ont connu 2 fois à Londres également, pas de bol) - Rupture d'une canalisation de circuit d'eau froide de clim en faux plancher (rouillée) entrainant une panne générale de clim - Problème électrique dernièrement - Problème de points chauds, puisque le dégagement calorifique des baies est bien supérieur à ce qu'il était au début des années 2000 Comparer une salle privée récente avec un DC de plusieurs centaines de baies âgé de 14 ans, c'est comme dire qu'un jeune de 20 ans à l'hygiène de vie douteuse est en meilleure santé qu'un mec de 50 ans qui fait du sport et qui a eu un problème physique. Pour moi un DC demande plusieurs années de fonctionnement pour qu'on puisse tirer un bilan. On se souvient aussi que Redbus Courbevoie a été considéré comme un bon DC à pas cher pendant des années avant de connaître une très grosse panne électrique il y a 10 ans dont on parle encore de nos jours. Pourtant ils n'en ont pas eu avant et ils n'en ont pas eu après. Il faut bien garder en tête que Level 3 est un site opérateur à la base et qu'il est vieux et n'a pas la qualité d'un DC neutre dont c'est le métier premier, mais qu'une salle maison ne l'est pas plus, même si elle n'a pas (encore) connu de problème. Il faut quand même souligner que Level 3 (j'exclus Global Crossing là) n'a pas eu de problème réseau pendant ces incidents, alors que le coeur de leur réseau parisien se concentre sur ce site (sur le circuit 48V) Frédéric ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Retour d'expérience: panne du DC Level3
Le 28/11/2014 13:38, Alexandre Legrix a écrit : Jusqu'a la prochaine panne majeur d'EDF dans ta région avec aucune idée du quand ça va revenir;-) Ou la prochaine canicule. On en reparle si tu le veux bien. Ah mais je parle du site en tant que tel :-) Je n'ai pas dis que je n'avais pas de serveurs AILLEURS. Ce qui d'ailleurs pour moi reste la seule et unique solution viable. Selon Frederic Comparer une salle privée récente avec un DC de plusieurs centaines de baies âgé de 14 ans, En l'occurence, la salle dont je m'occupe a plus de 15 ans, est très petite, mais s'est adapté au fil du temps avec les évolutions de besoins. Donc je suis d'accord avec ton analyse. Merci pour tes précisions ;) -- Manu Jacquet ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Galera Cluster
OK admettons alors voilà les versions : Debian Wheezy (à jour) MariaDB 5.5.40 et 10.1.1 (une seule version par Cluster) Du coup, c'est Galera 25.3.5. Il faut que j'essayer avec MariaDB 10.0.15 qui est plus stable. Le segfault était du à un problème avec des binlogs, je ne sais pas pourquoi. En supprimant tous les binlogs, je n'avais plus de segfault. En supprimant les options wsrep_% dans la config mysql et avant de supprimer ces binlogs, je n'avais plus les segfault. C'est donc le plugin Galera qui faisait segfaulter mysqld. Sinon, c'est curieux, mais j'ai reçu des retours négatifs off-list, et uniquement off-list... - Le problème des écritures simultanées sur plusieurs nodes, qui causent des deadlocks, revient à chaque fois - On m'a aussi signalé des problèmes de synchro de nodes. - ce n'est visiblement pas adapté aux taux d'écritures trop élevés - finalement la gestion d'un ensemble master-slaves semble plus fiable et plus facile à gérer en cas de crash d'une ou plusieurs nodes - les quelques success-stories concernent des clusters avec un fort taux de lecture Je vais continuer ma maquette, cette fois avec la version 10.0.15 de MariaDB, et ferais des tests supplémentaires sur la charge. Bon week-end ! Le 28 novembre 2014 10:50, Alexandre Legrix a...@bragonux.net a écrit : On 11/28/14 10:44, Greg wrote: Je ne souhaite pas préciser les versions pour ne pas rentrer dans un débat oui mais avec telle version de Percona ça marche par contre du coup tu n'auras pas la feature X de MariaDB etc ... Ce qui m'intéresse c'est un retour d'expérience en production. Ok alors sans entrer dans un debat de clocher puisque tu ne veux pas parler de version ... (Chose que je trouve débile, soit dit en passant) Sur des Gentoo (et/ou Debian) (Je ne dis pas la version) configurées aux petits oignons, avec des MariaDB (sans dire la version) Galera (pas de version du patch) dernière version de l’époque (mais je dis pas la date) (puisqu'on ne doit pas parler de version ) , ça marchait en production sans segfault ! avec un datadir d'environ 20Gb Tu vois a quel point c'est ridicule de ne pas vouloir donner de versions ? /fin -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Galera Cluster
Bonsoir. Franchement, le point le plus gênant dans ce système de cluster, c'est l'effet dominos quand il y a un problème de synchro (encore plus quand on se retrouve avec une erreur humaine et des tables créées en MyISAM, alors là, c'est une boucherie), en 5 mins, tout le cluster tombe, et t'as gagné un bootstrap-pxc... Je ne te cache pas que je suis d'accord avec les points que tu as résumé, ça représente mes 4 derniers mois à travailler sur cette techno. Bonne soirée et bon weekend ! On 11/28/2014 07:02 PM, Greg wrote: OK admettons alors voilà les versions : Debian Wheezy (à jour) MariaDB 5.5.40 et 10.1.1 (une seule version par Cluster) Du coup, c'est Galera 25.3.5. Il faut que j'essayer avec MariaDB 10.0.15 qui est plus stable. Le segfault était du à un problème avec des binlogs, je ne sais pas pourquoi. En supprimant tous les binlogs, je n'avais plus de segfault. En supprimant les options wsrep_% dans la config mysql et avant de supprimer ces binlogs, je n'avais plus les segfault. C'est donc le plugin Galera qui faisait segfaulter mysqld. Sinon, c'est curieux, mais j'ai reçu des retours négatifs off-list, et uniquement off-list... - Le problème des écritures simultanées sur plusieurs nodes, qui causent des deadlocks, revient à chaque fois - On m'a aussi signalé des problèmes de synchro de nodes. - ce n'est visiblement pas adapté aux taux d'écritures trop élevés - finalement la gestion d'un ensemble master-slaves semble plus fiable et plus facile à gérer en cas de crash d'une ou plusieurs nodes - les quelques success-stories concernent des clusters avec un fort taux de lecture Je vais continuer ma maquette, cette fois avec la version 10.0.15 de MariaDB, et ferais des tests supplémentaires sur la charge. Bon week-end ! Le 28 novembre 2014 10:50, Alexandre Legrix a...@bragonux.net mailto:a...@bragonux.net a écrit : On 11/28/14 10:44, Greg wrote: Je ne souhaite pas préciser les versions pour ne pas rentrer dans un débat oui mais avec telle version de Percona ça marche par contre du coup tu n'auras pas la feature X de MariaDB etc ... Ce qui m'intéresse c'est un retour d'expérience en production. Ok alors sans entrer dans un debat de clocher puisque tu ne veux pas parler de version ... (Chose que je trouve débile, soit dit en passant) Sur des Gentoo (et/ou Debian) (Je ne dis pas la version) configurées aux petits oignons, avec des MariaDB (sans dire la version) Galera (pas de version du patch) dernière version de l’époque (mais je dis pas la date) (puisqu'on ne doit pas parler de version ) , ça marchait en production sans segfault ! avec un datadir d'environ 20Gb Tu vois a quel point c'est ridicule de ne pas vouloir donner de versions ? /fin -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/ -- Cyril Davromaniak Lavier KeyID 59E9A881 http://www.davromaniak.eu ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Galera Cluster
Avec un HAProxy pour faire la répartition en frontal, ça n'aurait pas réglé ton problème ? Guillaume Hilt Le 28/11/2014 10:54, Cyril Lavier a écrit : Bonjour. J'ai mis en prod un cluster Percona XtraDB (donc Galera) de 5 noeuds. Franchement, je n'en suis pas déçu, ça marche très bien. Un point négatif, c'est la répartition de charge, j'ai mis le cluster derrière un BigIP, et au niveau des écritures, j'ai dû créer un pool à part en mode actif/passif, avec un noeud actif pour les écritures, sans ça, j'avais une trouzaine de deadlocks dans tous les sens, et même avec des modifications de code, de requêtes SQL ou de schémas, il m'en restait. En passant sur le pool avec un noeud actif en écriture, je dois avoir 1 ou 2 deadlocks dans la journée, ce qui est bien mieux qu'avant. Pour la stabilité, les seuls incidents étaient causés par des pebkacs, avec une désynchro de tous les noeuds et donc le cluster qui tombe. J'ai déjà une machine du cluster qui a grillée, et à part quelques alertes de supervision, et un cluster légèrement plus lent, je n'ai eu aucun impact en production. J'espère que ça va t'aider. Merci. *From: *Greg greg-fr...@duchatelet.net *To: *French SysAdmin Group frsag@frsag.org *Sent: *Friday, 28 November, 2014 10:44:22 *Subject: *Re: [FRsAG] Galera Cluster Je ne souhaite pas préciser les versions pour ne pas rentrer dans un débat oui mais avec telle version de Percona ça marche par contre du coup tu n'auras pas la feature X de MariaDB etc ... Ce qui m'intéresse c'est un retour d'expérience en production. Le 28 novembre 2014 10:36, Alexandre Legrix a...@bragonux.net mailto:a...@bragonux.net a écrit : Bonjour. En pratique, sur une maquette avec des vrais serveurs physiques et des vrais données venant de la prod, je me prends des segfault, des arrêts brutaux de mysqld, et une resynchro plutot aléatoire ... alors que cette solution est vendue pour améliorer la haute-dispo. Lorsque je l'avais test, et il y a déjà un moment dans MariaDB, je n'ai pas remarque de segfault. Peux tu effectivement nous en dire plus sur les versions que tu utilises, et aussi ce que tu as téléchargé, sur quel OS, etc ... ? Cdlt -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/ -- Cyril Davromaniak Lavier KeyID 59E9A881 http://www.davromaniak.eu ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
