Le Blog Utux

Je note un comportement assez désagréable depuis quelques temps. Le fait de simplement ouvrir le store Microsoft sur mon BallmerPhone Lumia 950 provoque une chauffe excessive et un vidage rapide de la batterie. En moins de 2h je passe de 100% à 20-30%. En fait l'appareil est tellement chaud qu'on pourrait le mettre dans un RTG à la place du plutonium (au moins ça réchauffe les doigts). Même quand je reboote le smartphone ça continue, et c'est pénible. Il s'est éteint la nuit dernière et ne m'a donc pas réveillé le matin... heureusement le chat l'a fait.

Il est difficile de trouver de l'aide sur le web car:

• Il y a de moins en moins d'utilisateurs de Windows Phone, donc on tombe souvent sur de vieux topics de 2014.
• Beaucoup de résultats peu pertinents qui concernent Windows sur desktop.
• Résponses inutiles du genre: vérifie tes applications en arrière plan, regarde le gestionnaire de consommation de batterie (qui ne dit rien d'utile), blablabla.

Mais il y a toujours de l'espoir et je suis tombé sur ce topic: Lumia 950 heat and battery drain. En fait c'est bien lié au Store Microsoft qui a des applications en cours de téléchargement ou de mise à jour dans un état bloqué. Et apparemment chez Microsoft les timeout ça n'existe pas, l'appareil va essayer de télécharger jusqu'à la mort. Donc il faut lister les téléchargements en cours et les stopper quand c'est possible. On essaie 10x puis on reboote et ça fini par fonctionner.

Quand on voit la merde qu'est Windows Update sur desktop et les problèmes que rencontrent les Lumia on se dit quand même que Microsoft et les mises à jour c'est toujours pas ça.

Article pense-bête. J'écris un petit rôle pour configurer firewalld, en gros je veux spécifier quelles interfaces et quels services il faut ajouter dans les zones. Mon idée c'est de définir tout ça dans un dictionnaire dans le playbook, et ensuite de récupérer les élements et sous-élements dans le rôle.

Voici ce que ça donne:

# install.yml

- hosts: nas

  roles:
    - nfs-server
    - firewalld

  vars:
    firewalld_zones:
      - zone: internal
        interfaces:
          - eth0
        services:
          - mountd
          - nfs
          - rpc-bind

  - name: Define zones for interfaces
    firewalld:
      zone: "{{ item.0.zone }}"
      permanent: true
      immediate: true
      interface: "{{ item.1 }}"
      state: enabled
    with_subelements:
      - "{{ firewalld_zones }}"
      - interfaces

  - name: Allow services for zones
    firewalld:
      zone: "{{ item.0.zone }}"
      permanent: true
      immediate: true
      service: "{{ item.1 }}"
      state: enabled
    with_subelements:
      - "{{ firewalld_zones }}"
      - services

Mouais. C'est quand même loin d'être clair ou évident. Mais c'est le seul moyen que j'ai trouvé pour le moment. Si quelqu'un connaît une méthode plus propre/lisible je suis preneur.

Sport et santé:

• Tenir 3 mois d'entraînement intensif pour le Marathon.
• Finir le marathon (objectif 4h).
• Faire de la musculation.
• Maigrir.

Perso:

• Acheter un appart.
• Changer de taf.
• Rejoindre des assos.
• Que ma consommation de viande tende vers zéro.

Geek:

• Migrer de docker-compose vers docker-swarm, kubernetes ou rancher.
• Écrire ces fichus articles sur Docker que j'ai en réserve depuis 1 an.

Fallout 4 c'est comme Skyrim, c'est mieux avec des mods. Le plus signifcatif à mon avis pour Skyrim était SkyUI qui remplaçait l'interface clairement conçue pour les consoles par un système de fenêtres plus adapté au PC, ajoutant même au passage des indicateurs dans le HUD très utiles. Quant à Fallout 4, je pense avoir trouvé LE mod qui m'a laissé sur le cul, il s'agit de Sim Settlements.

Sim Settlements attaque le système de settlements (colonies) qui de base n'est pas terrible voire énervant pour l'améliorer, l'automatiser et le rendre plus vivant. Ainsi vous pouvez placer des zones dans lesquels vos habitants vont construire eux-même leur maison, magasin ou jardin, chacun étant généré au hasard. A cela s'ajoute un système (optionnel) de taxes et divers indicateurs. Beaucoup disent que ce n'est pas une amélioration, c'est ce que Fallout 4 aurai du être et je plussoie. Des settlers capables de vivre sans le joueur, pas trop tôt!

Fallout 4 est un jeu que j'avais mis de côté, car après ~300h de jeu j'ai fait le tour. Mais ce mod m'a donné envie de m'y remettre juste pour m'émerveiller devant les maisons qui se construisent toutes seules, qui s'améliorent, et qui rendent les settlements plus immersifs. Merci kinggath!

• Page sur le Nexusmod
• Trailer vidéo du mod
• Présentation vidéo du mod par Oxhorn

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.

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.

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.