Re: [FRsAG] Pour le fun
Comme une petite "bash bomb" connue qui se fork en permanence. http://www.cyberciti.biz/faq/understanding-bash-fork-bomb/ Pour le uptime je n ai jamais rien vu de tel qu une machine netware https://cdn.arstechnica.net/wp-content/uploads/2013/03/intel-server-uptime-640x215.jpg Après il y a sûrement quelques vieilles machines unix qui trainent qui n ont toujours pas rebootée...___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] La question (sérieuse) du Vendredi : pourquoi tant d'utilisateurs d'Ansible ?
Juste je confirme pour les PR dans salt, ayant vu mes codes acceptes puis apparaitre dans la version en dev puis dans la derniere release 2016.11 8-). il est d ailleurs regrettable qu il n y en ai pas plus finalement :) Message d'origine De : Nathan delhaye Date : 09/12/2016 17:32 (GMT+01:00) À : Gilou Cc : French SysAdmin Group Objet : Re: [FRsAG] La question (sérieuse) du Vendredi : pourquoi tant d'utilisateurs d'Ansible ? Hello, De mon côté j'ai remplacé Puppet par Salt il y a un an environs. Le choix s'est fait entre Chef, Puppet, Ansible et Salt lorsque nous avons du refaire notre infra. Puppet et Chef ont été éliminés bien vite parce que je Déteste le ruby (non mais sérieux "(var ||= []) << var" comment on peut trouver ça simple a lire?? ) Le choix final s'est porté sur Salt pour 4 raisons principales a l'époque : - La possibilité de travailler en mode minion/master ET en mode ssh : permet d'avoir une infra complexe et des scripts de bootstrap simples - La mine intégrée, qui remplace très efficacement etcd - Le système de reactor, pratique pour faire du monitoring réactif ou de la coordination de cluster - La scalabilité et rapidité d'éxécution des states. Concernant la scalabilité/rapidité d'éxécution, je m'explique : lorsque j'ai un grand nombre d'états (users, fichiers, archives, certificats, etc...) sur un serveur, le cache de Salt permet d'accélérer grandement les choses. Sur un test sur un serveur un peu lourd, type Wordpress du marketing/SEO (http://bit.ly/2hdbhxN) avec une pétachiée de vhost, je passe de 2 minutes d'éxécution avec le script ansible à 10-15 secondes avec Salt lorsqu'il y as peu de modif a faire (exemple, créer un nouveau vhost). Pour moi c'est le cas le plus important a benchmark dans la mesure ou le temp d’exécution lors du setup initial va être sensiblement le même parce que les deux systèmes vont devoir exécuter le package manager, installer des trucs, créer des users, générer des certificats, etc, etc ce qui prend généralement plus de temps que le calcul des diff par le système d'industrialisation. Cela dit, le ticket d'entrée sur Salt est bien plus élevé que sur Ansible. On se rapproche plus de Chef que de la philosophie Ansible proche du "rsync script.sh server: && ssh server script.sh" Après un peu de recul, en plus des 4 points qui ont motivé le choix de la techno voila mon avis sur Salt: - Systèmes Modules/States/Formulas/Grains qui sépare bien les différents composants d'un système d'industrialisation absolument jouissif a utiliser. - Modules/States/formules faciles a développer - Possibilité de faire du quick & dirty dans les formules avec du pur Yaml/Json, mais aussi des trucs bien complexes en Python - Les gars de Salt sont réactifs au merge de PR sur leur git A+ Le 9 décembre 2016 à 15:59, Gilou a écrit : Le 09/12/2016 à 15:47, Jonathan Leroy a écrit : > Salut à tous, > > J'ai l'impression ces derniers temps qu'il y a de plus en plus > d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu > partout sur l'Internet. > Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible > plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ? Pas plutôt, je ne les utilise pas pour la même chose. Pourquoi l'adoption ? Parce que : - 0 infrastructure pour commencer => (SSH / DNS + inventaire, le pré-requis est très bas) - Accès ultra-simple => (ad-hoc = 0 apprentissage, 1er playbook en 5 minutes) - Passer d'un shell script à un playbook (salement) : 5 minutes - Industrialiser et comprendre l'idempotence, easy - Se plugger sur un inventaire (cloud ou pas) existant (amazon, openstack, ...) easy. Et parce que.. ça répond au besoin de mise en conformité en passant par le code, propre d'une mise ne place DevOps, et facilite grandement l'idempotence et l'orchestration à grande échelle. Pourquoi ça ne remplace pas Salt, Puppet ou autre (du moins, sans Tower). Les outils basés sur un agent sont plus faciles à manipuler à plusieurs, pour définir des gestions de privilèges ou dépendre d'un CMDB bien violent, et gérer les accès simultanés. Ils sont aussi plus lourds. > > J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait > pas. Est-ce seulement le fait qu'il soit agentless ? Il est aussi lent que SSH l'est, malgré les optimisations diverses (notamment très ressenties en 2 puis en 2.2). Pour ce qui est du comparatif, je ne crois pas que Puppet ou Salt puisse la ramener sur la vitesse d'exécution, mais je pense aussi que c'est un critère assez secondaire. Ne "scale" pas, j'aimerais bien une élaboration. Il ne gère pas facilement les accès simultanés et la gestion de privilèges, par nature, mais il scale très bien, et les callbacks sont très facile d'accès pour les besoins (ou bien, on achète Tower). Bref, Ansible, ça rox, ça demande rien, et ça claque. @+ Gilou __
Re: [FRsAG] systemd vs les adminsys
Il te reste BSD et son init ;) https://www.textplain.net/blog/2015/problems-with-systemd-and-why-i-like-bsd-init/ Message d'origine De : Sébastien FOUTREL Date : 13/12/2016 13:54 (GMT+01:00) À : Jonathan Leroy Cc : French SysAdmin Group Objet : Re: [FRsAG] systemd vs les adminsys Aahhaha. Et la gestion des logs, et la gestion des montages et surement d'autres choses :DRegarde aussi ce qui se passe quand tu veux demarrer un service et que systemd ouvre une socket reseau avant meme que le demon soit lancé :D Essaye de faire un swapoff -a et regarde ce qu'il se passe au bout de quelques secondes ou minutes en fonction de ce que va trapper systemd.Malheureusement comme dit plus tot, systemd c'est parti d'un bon sentiment mais si on avait voulu bosser sur macosX on aurait fait ce choix. Dorenavant on a plus vraiment le choix... Le 9 décembre 2016 à 15:27, Jonathan Leroy a écrit : Le 9 décembre 2016 à 14:59, Dominique Rousseau a écrit : > C'est ça le vrai probleme de systemd sur des serveurs, c'est que ça a un > coté bulldozer, qui remplace les outils de configuration reseau, le > collecteur de logs, etc. Systemd arrive avec tout un ecosysteme qui fait > qu'on a plus "un Unix" (un peu comme MacosX), avec des fichiers plats > editables et lisibles par un humain adminsys, des fichiers logs qu'on > peut grep/awk/..., des noms d'interface reseau deterministes, etc. Mais la plupart de ces fonctionnalités sont désactivables, voire désactivées par défaut. C'est le cas par défaut sous Debian, qui n'utilise que la partie "init" de Systemd. -- Jonathan Leroy. ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] [MISC] - Desactiver la modification date acces fichiers sous Linux
Pareil. Utile pour accélérer un peu les accès, surtout pour des stockages spécifiques. Indispensable pour les ssd avec discard : https://wiki.archlinux.org/index.php/Solid_State_Drives Sinon, dans les autres cas, personnellement, je trouve ça indispensable. Je me suis même fait une petite fonction bash pour afficher les N (defaut = 10) derniers trucs modifiés (basé sur ls et ses options, pas stat) :https://gist.github.com/remyd1/57f825ca6880ae74f59d Message d'origine De : Ludovic Scotti Date : 18/02/2017 21:22 (GMT+01:00) À : Kevin Lemonnier Cc : French SysAdmin Group Objet : Re: [FRsAG] [MISC] - Desactiver la modification date acces fichiers sous Linux Dans mon taf on utilise souvent ces options sur des solutions de backup avec déduplication.Ca améliore en effet grandement les perfs Le 18 février 2017 à 20:34, Kevin Lemonnier a écrit : > La question que je pose est que effectivement trouvez-vous vraiment que > << La date d’accès d’un fichier n’a que peu d’intérêt >> ? > Et si oui dans quel cas ? Ça arrive d'utiliser les autres pour faire de la place, supprimer tous les fichiers qui ont plus de 2 ou 3 jours par exemple, mais la date d'accès .. J'ai du mal à imaginer une utilisation pour. Éventuellement lister les fichiers qui servent vraiment à quelque chose, qui pourraient être supprimé / déplacé sur un storage lent. Mais bon, c'est pas tous les jours. -- Kevin Lemonnier PGP Fingerprint : 89A5 2283 04A0 E6E9 0111 ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Baisser le cout du stockage - grosse volumétries
Bonjour, Pour parler purement matériel, on commence à voir apparaitre des baies ou serveurs (nas) 4 ou 5U où tu stockes ~90 disques (ex : baie Dell Md1280 à 84 disques sur 5U, Supermicro et chassis serveur 90 disques, serveurs ou baies zstor...). Avant, on était plutôt sur du 60 disques (backblaze, storinator, ddn...). Remplis en disques de 10To, c'est imbattable en densité et en prix du To/an. Pour info, on a un projet de stockage à peu près similaire pour un besoin avoisinant le 1Po. On s'oriente vers du serveur/DAS en Zfs car on sert du fichier derrière. Pour de la résilience, de la sécurité, l'évolutivité, le stockage objet c'est super, mais si votre besoin est différent, il y a des alternatives. A+ Message d'origine De : Fabrice Vincent Date : 10/10/2017 15:37 (GMT+01:00) À : frsag@frsag.org Objet : Re: [FRsAG] Baisser le cout du stockage - grosse volumétries Bonjour, A job-1, sur des volumétrie inférieures, on était parti sur des NAS Synology. Avec les options cache rw SSD ou full SSD, le iSCSI Target, la HA, etc. on obtiens des fonctionnalité assez proches des baies de stockage de grand constructeurs pour une fractions du cout ! D'autant plus qu'on peut acheter les disques que l'on veut ou on veut (voir quand même la liste des HD certifiés compatibles suivant la baie). Coté couts humain, l'effort de mise en œuvre n'est pas le même qu'avec un CEPH, Gluster ou autre ! En terme de volumétrie, leur plus grosse baie actuelle a 16 emplacements et accepte 2 extensions de 12, soit un total de 40 HD. Imaginons 4 SSD en RAID 10 pour le cache RW, reste 36 HD de 12 To soit 432 To brut. Après je ne suis pas un expert SAN et je n'ai jamais eu l'occasion de comparer en live avec une baie HP, NetAPP, EMC, ou autre (c'était hors budget !). Mais vu le différentiel prix, AMHA ça se vaut le coup de faire un PoC (avec des baies plus petites). Au pire ça ourra servir pour stocker les sauvegardes. :) mes 2 cents... Bonne journée, Fabrice Le 09/10/2017 à 23:48, Bruno LEAL DE SOUSA a écrit : Bonjour à tous, Je suis face à une problématique, que beaucoup aujourd’hui doivent rencontrer. Dans ce monde hyperconnecté, on se retrouve souvent à gérer des grosses volumétries. Aujourd’hui, nous sommes équipés avec des baies HPE 3PAR 7200 (SSD/FC/NL) et 8400 (Full SSD). Ces baies sont vraiment super, on en content du service. Cependant le cout du stockage au To est assez important. Cela allait tant qu’on gérait des quantités « Raisonnables » mais là dernièrement ceci explose et ça ne devrait pas s’arrêter. Passage de 50To utiles à 200 en 3 ans. Si vous avez ce genre de réflexion, n’hésitez pas ! Partager vos pensées et vos solutions pour faire face aux couts astronomiques du stockage. Bonne soirée à tous ! -- Bruno LEAL DE SOUSA Ingénieur Système et Infrastructure ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
