Le Blog Utux

HTTP 200 GET /

Le minage, le minage et encore le minage

Rédigé par uTux 6 commentaires

Note: j'ai mis beaucoup de temps à écrire cet article, ne sachant pas comment le tourner sans tomber dans des biais ou de la désinformation. Il ne s'agit que de mon avis, vous pouvez me traiter de vieux con n'ayant pas compris le système, vous avez probablement raison, insultez moi dans les commentaires j'assume totalement. C'est totalement de la philosophie de comptoir.

Quand on parle de cryptomonnaie je suis pense principalement à Bitcoin. Même si je n'y comprends pas grand chose j'ai longtemps eu une image positive, l’émergence d'une alternative au système bancaire, une monnaie geek sans frontière totalement décentralisée et dématérialisée, c'est plutôt cool. Si vous non plus vous n'y comprenez rien, vous pouvez consulter cette vidéo de Science étonnante qui explique le principe des cryptomonnaies et des blockchain.

Il s'avère que les cryptomonnaies ont besoin de puissance de calcul sur le réseau pour valider les transactions et générer de nouvelles unités, on appelle cela le minage. C'est un processus nécessaire au système pour rester intègre et décentralisé. Les ordinateurs qui "minent" sont récompensés en gagnant eux-même des bitcoin (ou autre monnaie). Il semble que (au début) la rémunération était assez conséquente, ce qui a mené à l’émergence d'un nouveau business, le minage en masse. On ne mine plus pour participer au système, on mine pour l'argent, le vrai argent en $$$, dans des datacenter avec des fermes de serveurs, ou encore chez soit en empilant des cartes graphiques, ce qui a d'ailleurs mené a la pénurie et l'explosion du prix des AMD RX500.

Il y a un mois, le site bitcoin.fr estimait que le réseau Bitcoin consommait "une dizaine de milliards de kWh par an", il faut ajouter à ce chiffre les autres cryptomonnaies car oui elles sont très nombreuses (Etherum...). Pour l'aspect écologique on repassera. Bon, j'avoue que ce chiffre absolu est assez difficile à interpréter car il faudrait connaître l'impact des vraies monnaires pour savoir si Bitcoin est pire ou non.

A cela il faut ajouter la spéculation très importante. On parle en ce moment du Bitcoin à $12 000 et cet été il y a eu un cratch éclair de l'Etherum qui a fait passer temporairement sa valeur de $317 à $0,10. En fait la monnaie est tellement imprévisible que Steam ne l'accepte plus, la raison invoquée étant les frais de transaction ($7,3 !!!) mais on imagine aussi que les importantes fluctuations du cours ont joué (un client se faisant rembourser un jeu alors que la valeur du Bitcoin a monté peut être problématique). On achète de la cryptomonnaie quand le cours est bas et on la revend quand il augmente, c'est la bourse...

Commitstrip, 2014 (cliquez sur l'image pour accéder à ce site génial).

Bon jusqu'ici j'ai utilisé des arguments de vieux con, mais on peut monter d'un cran: on sait maintenant miner en javascript, ce qui permet donc d'intégrer des scripts dans les pages web pour faire miner les visiteurs, à leur insu. Au passage je remercie le javascript pour avoir transformé nos navigateurs web en clients lourds, il y a 10 ans on pouvait "surfer" avec 128MB de RAM, aujourd'hui 1GB est un minimum, et encore c'est en utilisant des bloqueurs et divers filtres. Petit récapitulatif de la situation et des nombreux abus avec le minage sur le web. uBlock Origin bloque ces applets, on peut le tester chez coinhyve (un petit applet permet d'afficher la vitesse de minage, il reste normalement à zéro).

En ce qui me concerne le minage dans les pages web est la goutte d'eau qui a fait déborder le vase. Y'en a marre du minage, tout le monde ne parle que de ça, c'est l'enjeu de la décennie, on n'utilise pas les cryptomonnaies pour s’affranchir du système bancaire classique, on les utilise pour se faire un max de pognon réel ($$$) de manière propre ou impropre. Donc on nuit, on pollue, on avance pas. C'est presque une expérience sociologique: on a pas besoin des banques ou des politiques pour avoir de la spéculation, c'est humain et universel, ça fait réfléchir.

Fin de la philosophie de comptoir.

Mauvaise expérience avec Ceph

Rédigé par uTux 14 commentaires

Ceph fait du stockage distribué. Il permet de répartir des données sur plusieurs machines avec réplicas, assurant ainsi une certaine sécurité et résilience.

Ceph logo

Sauf que ça c'est la théorie, en pratique mon expérience a été assez mauvaise et non seulement source d'interruptions de service mais aussi d'un niveau de stress très important (jusqu'à ne plus dormir la nuit). Parce que oui perdre un serveur de prod n'est déjà pas agréable, mais quand il s'agit du stockage c'est encore pire.

Commitstrip
Un admin qui bosse avec Ceph

Problème 1: l'usine à gaz

Ceph est gros, très gros, pour le compiler prévoyez au minimum 8GB de ram (sous peine de faire exploser votre machine) et plusieurs heures.

Ensuite pour être à l'aise prévoyez des machines bien dimensionnées (Xeon), beaucoup de RAM (1GB par TB) et du stockage SSD pour la journalisation. A l'usage ne vous étonnez pas de voir la RAM et la swap proche de la saturation, c'est le rythme de croisière.

Et puis l'architecture n'est pas simple il y a les OSD, les PGs, les différents services, et les logs parfois pas très clairs qui vous disent que la reconstruction est bloquée sans vraiment donner de raison.

Problème 2: les bugs

Sur la version Kraken (11.2) il existe une fuite de mémoire avec le service ceph-mgr. La solution est donc de le couper. Sauf que son rôle est justement de contrôler l'utilisation de la mémoire, donc le serveur va naturellement gonfler au fil des mois jusqu'à finir par exploser en vol. Il faut donc régulièrement lancer ceph-mgr puis le couper.

Le hic, c'est que dans le cas où votre serveur est déjà bien chargé (RAM + swap), le lancement de ceph-mgr ajoute un poids supplémentaire ce qui peut amener des lag sur le cluster le temps que la mémoire baisse... et ça c'est très mauvais. Dans mon cas cela a fait basculer plusieurs machines virtuelles en readonly.

Problème 3: ceph-deploy

Avec la mouvance devops il est de plus en plus courant de vouloir installer les choses sans devoir mettre les mains dans le cambouis, faire du sysadmin sans rien connaître en sysadmin quoi. Et c'est problématique. Certes c'est rapide et facile, mais en cas de panne on ne sait pas quoi faire car on ne sait pas comment marche le système.

Ceph-deploy fait le boulot à votre place, et dans le cas où ce n'est pas vous qui avez monté l'infra, si vous ne disposez pas du répertoire contenant les clés et la configuration, bon courage pour manipuler le cluster (ajout ou retrait de nodes). De plus ceph-deploy réserve des surprises en installant pas forcément la version qu'on lui demande...

Problème 4: les performances

Même avec un setup assez costaud (plein de RAM et de SSD) les I/O des VM qui sont stockées dessus sont décevantes. C'est un ressenti, mais à l'aire du SSD et/ou du stockage en RAID10, une installation d'une VM debian stockée sur cluster Ceph parait interminable.

Problème 5: résilience

Dans un cluster de 3 nodes on se dit qu'on est tranquilles car on peut en perdre 2 et continuer à fonctionner, un peu comme avec un RAID1 de 3 disques. Sauf qu'en pratique, il faut au minimum 2 nodes actives... Et oui, j'ai testé sur un cluster Ceph 0.96 et 11.2, dans les deux cas les données ne sont plus accessibles s'il ne reste qu'une seule node en vie.

Problème 6: targetcli

C'est le daemon iscsi de Ceph. Le problème ? Il perd sa conf partiellement ou totalement à chaque reboot. Prévoyez un targetctl restore systématique et un downtime possible si vous devez effectuer cette opération.

Conclusion: abandon

Alors que Ceph est censé apporter une continuité de service et donc un sérénité pour les admin, j'ai expérimenté le contraire. Les nombreux downtimes et les fois où j'ai été à deux doigts de perdre l'intégralité du stockage (et donc des machines virtuelles) m'ont causé des nuits blanches d'angoisse.

Les VM sont en cours de migration vers un SAN artisanal à base de Debian + iscsitarget. Il n'est peut-être redondé mais il est fiable, il n'y a pas de fuite de RAM, et s'il y a le moindre pépin nous connaissons les couches de A à Z pour pouvoir diagnostiquer.

En ce qui me concerne Ceph est une usine à gaz qui n'est pas production ready et j'espère ne plus avoir à y toucher de ma vie.

Justice League, garanti sans Snyder

Rédigé par uTux Aucun commentaire

Je ne suis pas trop fan de cinéma mais j'aime les films de Snyder. Au delà du divertissement il y a une profondeur et une réflexion, par exemple dans le décrié Batman V Superman la représentation des media est assez sévère. On peut même dire que c'est à travers la télévision que Batman développe une haine pour Superman jusqu'à ce qu'il réalise lors de la "scène Martha" qu'il n'a pas affaire à un dieu mais à un fils qui veut sauver sa mère. Et moi j'aime bien ce genre de prise de risque, mais visiblement ce n'est pas le cas de tous, le film ayant eu beaucoup de retours négatifs (parfois justifiés, parfois non).

Mon intérêt pour Snyder et mon manque de connaissance des héros DC m'ont poussé à aller voir le film.

Justice League

Et en fait c'est plutôt bien, pas mal de grosses scènes de baston, beaucoup de temps consacré à la construction de l'équipe (alors que cela aurait pu être rushé), des personnages assez réussis, du Jason Momoa (aka Ronan Dex de Stargate Atlantis) qui nous fait du Jason Momoa bourrin et bestial, un méchant qui veut tuer la gentille, de l'humour, ça envoie du lourd. Il n'y a cependant pas le côté Snyder auquel je m'attendais. Aucune réflexion, aucune profondeur, c'est un blockbuster tout à fait classique, la réponse (avec 5 ans de retard) de DC aux Avengers de Marvel. Et même si j'ai "kiffé" le film, je regrette quand même ce manque.

Difficile de savoir ce qui s'est passé. Le film a-t-il été "moulé" par la production pour faire face aux Avengers ? Ou est-ce du au drame qui a touché Snyder et qui l'a incité à passer la main ?

Pour le coup je ne met pas mon "seal of approval" mais je le recommande quand même !

Dans quel sens faut-il backuper ses serveurs ? Borg, backuppc

Rédigé par uTux 17 commentaires

Attention ceci n'est un comparatif entre backuppc et borg mais une courte réflexion. Je cherche à me débarrasser de backuppc pour les raisons suivantes:

  • Sous le capot c'est l'usine à gaz et c'est un enfer à installer surtout avec le webui quand votre distribution ne le propose pas ou pas complètement (genre FreeBSD).
  • Je n'aime pas du tout la planification des backup qu'on ne peut pas définir à des horaires (sauf avec des crons).
  • Il n'est pas disponible dans Nix alors que je migre vers NixOS (j'ai songé à le packager, mais cela me semble trop hardcore pour débuter).

Du coup j'examine les solutions alternatives de backup et tout le monde ne parle que de borg. Ce logiciel a l'air intéressant mais il semble plus adapté à la sauvegarde d'une machine individuelle qu'à l'utilisation dans un parc de centaines de serveurs. En effet les sauvegardes avec Borg se font en "push", il faut l'installer sur chaque serveur qui va ensuite pousser ses sauvegardes vers un repo distant. Avec Backuppc c'est du "pull", un unique serveur se charger d'aller chercher les données de vos serveurs distants.

Je pense que les deux solutions se défendent. L'avantage du pull (backuppc) c'est qu'on centralise la gestion, la surveillance et le stockage en un point, il n'y a rien à faire sur les serveurs. L'inconvénient est que votre serveur de sauvegarde doit disposer des accès root à l'intégralité de votre parc, ce qui peut constituer une faiblesse en terme de sécurité. Le push (Borg) est beaucoup plus sécurisé, par contre il faut l'installer et le gérer sur chaque machine ce qui ne doit pas être évident quand on en a des centaines.

La question est de savoir qui a raison. Faut-il faire ses sauvegardes en push et privilégier la sécurité ou en pull et privilégier la facilité de gestion ?

La difficulté de lâcher Windows Phone

Rédigé par uTux 5 commentaires

La semaine dernière j'ai vu passer le Nokia 5 en vente flash à 159€ (contre 199 plein pot), j'ai sauté sur l'occasion. J'ai fait ce choix principalement pour deux raisons:

  • Je n'ai jamais été déçu des Nokia, au contraire.
  • Le constructeur affirme fournir un système Android vanilla avec promesse de le mettre à jour, idéal pour moi qui déteste les surcouches.

Et après l'avoir reçu... mouais. L'appareil en soi est très bien mais il est trop grand pour moi, la coque est froide et glissante, et il lui manque l'USB-C et la charge sans fil pour me satisfaire. De plus je n'avais jamais touché à Android 7 et je n'aime vraiment pas, on a perdu tout l'aspect coloré et vif de la version 4.4 (que j'utilisais quand j'avais un Nexus 4) et il y a quelques désagréments comme le clavier et la barre du haut qui masquent le champ de saisie de SMS en mode paysage. Pour le reste il avait l'air bien, j'ai eu 4 mises à jour à la suite pour me retrouver en Android 7.1.1, donc à priori Nokia tient ses promesses. Les photo en intérieur avaient l'air plutôt correctes ce qui n'est pas très courant pour des appareils à ce tarif là.

Je n'arrive pas à abandonner mon Lumia 950. Même s'il n'y a plus aucune application tierce, il marche bien et fait des photo de fou même dans la pénombre sans flash. Et quand on a gouté à la charge sans fil, difficile de s'en passer. Du coup, le Nokia 5 sous Android a été renvoyé, j'ai demandé un remboursement. Je repousse mon retour à Android pour beaucoup plus tard, peut-être même à jamais...

Fil RSS des articles