homelab

Blog

  • Installer tailscale

    Pour pouvoir se connecter à son environnement homelab depuis n’importe quelle connexion wifi.

    Etape 1 : choisir le lxc qui va accueillir tailscale .

    Etape 2 saisir le code directement sur le nœud hébergeant le lxc

    bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/addon/add-tailscale-lxc.sh)"

    pour retrouver les infos liens

    ensuite dans le lxc il va falloir redémarrer et activer le service 

    echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf

    puis

    sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale up --advertise-routes=192.168.10.0/24

    pour finir suivre les indications de tailscale en ligne pour activer et valider

  • PBS monter samba au demmarage

    Guide : Montage CIFS Automatique au Démarrage

    Monter un partage réseau (CIFS) au démarrage de manière fiable

    Un guide pour résoudre le problème de montage `fstab` qui nécessite un `mount -a` manuel après le boot.

    1. Le Diagnostic : Pourquoi le montage échoue-t-il au démarrage ?

    Votre analyse est correcte. Le problème que vous rencontrez est très courant. Au moment où le système lit le fichier /etc/fstab pour monter les disques, le service réseau n’est très probablement pas encore actif.

    Par conséquent, votre VM essaie de contacter l’adresse IP 192.168.10.246 avant même d’avoir une connexion réseau fonctionnelle. L’opération échoue logiquement.

    Lorsque vous lancez mount -a manuellement plus tard, le réseau est cette fois-ci bien établi, ce qui permet au montage de réussir. L’option nofail dans votre ligne fstab empêche le système de bloquer au démarrage à cause de cet échec, mais ne résout pas le problème de fond.

    2. La Solution Recommandée : Utiliser `systemd`

    Plutôt que d’utiliser un script qui lancerait mount -a, la méthode moderne et la plus robuste sous les systèmes Linux récents (comme celui de Proxmox) est d’utiliser les unités de service de systemd.

    L’avantage principal de systemd est sa gestion des dépendances. Nous pouvons lui dire explicitement : « Ne tente de monter ce partage réseau qu’une fois que le réseau est bien en ligne ».

    Nous allons créer deux petits fichiers de configuration :

    • Unité `.mount` : Décrit *comment* monter le partage (similaire à la ligne `fstab`).
    • Unité `.automount` : Indique à `systemd` de monter ce partage *automatiquement* dès qu’un programme essaie d’accéder au dossier de destination (/mnt/freepro). C’est très efficace et résilient.

    3. Tutoriel Pas-à-Pas

    Étape A : Nettoyer `/etc/fstab`

    Pour éviter les conflits, commencez par commenter ou supprimer la ligne de montage CIFS de votre fichier /etc/fstab. Vous pouvez la commenter en ajoutant un # au début.

    #//192.168.10.246/backup /mnt/freepro cifs guest,uid=34,gid=34,file_mode=0660,dir_mode=0770,nofail 0 0

    Étape B : Créer l’unité `.mount`

    Le nom du fichier doit correspondre au chemin de montage. Pour /mnt/freepro, le fichier sera mnt-freepro.mount. Créez ce fichier dans /etc/systemd/system/.

    Commande pour ouvrir l’éditeur de texte nano :

    $ nano /etc/systemd/system/mnt-freepro.mount

    Collez le contenu suivant dans le fichier :

    [Unit]
Description=Montage du partage CIFS Freebox Pro

[Mount]
What=//192.168.10.246/backup
Where=/mnt/freepro
Type=cifs
Options=guest,uid=34,gid=34,file_mode=0660,dir_mode=0770,nofail
TimeoutSec=30

[Install]
WantedBy=multi-user.target

    Enregistrez (Ctrl+O) et quittez (Ctrl+X).

    Étape C : Créer l’unité `.automount`

    Maintenant, créez le fichier qui va surveiller le dossier et déclencher le montage.

    Commande :

    $ nano /etc/systemd/system/mnt-freepro.automount

    Collez ce contenu :

    [Unit]
Description=Point d'automontage pour Freebox Pro

[Automount]
Where=/mnt/freepro
TimeoutIdleSec=600

[Install]
WantedBy=multi-user.target

    Enregistrez et quittez.

    Étape D : Activer les services `systemd`

    Il faut maintenant informer `systemd` de ces nouveaux fichiers et activer le service d’automontage pour qu’il se lance au démarrage.

    $ systemctl daemon-reload $ systemctl enable --now mnt-freepro.automount

    La commande enable --now active le service pour les prochains démarrages ET le démarre immédiatement.

    4. Vérification Finale

    À ce stade, le montage devrait déjà être actif. Vous pouvez vérifier avec la commande :

    $ df -h | grep freepro

    L’épreuve du feu est le redémarrage. Lancez un reboot de votre machine.

    $ reboot

    Une fois la VM redémarrée, connectez-vous et essayez d’accéder au contenu du dossier, par exemple avec un ls. Le simple fait de tenter d’y accéder déclenchera le montage.

    $ ls -l /mnt/freepro

    Si les fichiers de votre partage s’affichent, la mission est accomplie ! Le montage est maintenant automatique, fiable et géré proprement par le système.

    © 2025 Guide Interactif. Construit pour résoudre les problèmes, une étape à la fois.

  • optimisation nvme usb et sata

    Optimisation Ceph – Tuto Final Complet

    Optimisation I/O Ceph : Guide Tutoriel

    Guide complet pour la configuration logicielle de vos OSDs NVMe (sur SATA et USB 3.1) afin d’améliorer la tolérance aux latences Ceph.

    1. Diagnostic et Prérequis

    Vos erreurs de latence (*slow ops*) proviennent des connexions non optimales de vos disques. Cette optimisation logicielle est un palliatif essentiel.

    🚨 OSD sur USB 3.1 (/dev/sdd)

    Le pont USB (JMicron, 152d:a583) est la source principale d’instabilité, d’où la nécessité d’augmenter la tolérance Ceph.

    ⚙️ OSD sur Adaptateur SATA (/dev/sda)

    La performance NVMe est limitée par le bus SATA, nécessitant une configuration I/O optimisée.

    Vérification de l’Ordonnanceur I/O

    Vérifiez l’ordonnanceur actuellement en place sur vos OSDs. Pour les SSDs, l’idéal est [none] ou [noop].

    cat /sys/block/sda/queue/scheduler cat /sys/block/sdd/queue/scheduler

    Résultat attendu (OK) : [none] ou [noop]

    1.1 Modification Manuelle de l’Ordonnanceur (Temporaire)

    Si la vérification montre un ordonnanceur non optimal (ex: mq-deadline), changez-le immédiatement. Ce changement n’est pas persistant :

    Commandes de Modification :

    echo noop > /sys/block/sda/queue/scheduler echo noop > /sys/block/sdd/queue/scheduler

    Validation de la Modification :

    cat /sys/block/sda/queue/scheduler

    Résultat attendu : [noop]

    2. Étape 2 : Fichier de Configuration UDEV (Rend les modifications permanentes)

    Création du Fichier : /etc/udev/rules.d/99-ceph-osd-tune.rules

    Ce fichier applique des optimisations avancées (Ordonnanceur, Taille de file d’attente, etc.) pour les SSDs et inclut le **correctif critique** `rq_affinity=0` pour la stabilité USB.

    Contenu exact à insérer (Copier et Coller)

    # Fichier: /etc/udev/rules.d/99-ceph-osd-tune.rules
# But: Optimiser les paramètres I/O pour tous les SSDs utilisés par Ceph.

# Règle pour cibler tous les périphériques de bloc non rotatifs (SSD/NVMe)
# ATTR{queue/rotational}=="0" identifie les SSD.
ACTION=="add|change", SUBSYSTEM=="block", ATTR{queue/rotational}=="0", KERNEL!="sr*", GOTO="ceph_ssd_tune"

GOTO="ceph_tune_end"

# --- Optimisation SSD/NVMe ---
LABEL="ceph_ssd_tune"

# 1. Ordonnanceur d'E/S: none (Idéal pour BlueStore sur SSD, minimisant la surcharge)
ATTR{queue/scheduler}="none"
# 2. Taille de la file d'attente logicielle (nr_requests): Augmentée à 256 pour les rafales d'E/S
ATTR{queue/nr_requests}="256"
# 3. Profondeur de file d'attente matérielle (queue_depth): Augmentée à 32 (pour SATA/USB)
# Remarque: Cette valeur dépend de l'adaptateur.
ATTR{device/queue_depth}="32"
# 4. Lecture Anticipée (Read-Ahead): 4MB pour améliorer les opérations séquentielles
ATTR{queue/read_ahead_kb}="4096"

# 5. Affinité de Requête (rq_affinity): CORRECTION CRITIQUE
# Rétabli à "0" pour éviter la dégradation des performances CPU/USB.
ATTR{queue/rq_affinity}="0"

GOTO="ceph_tune_end"

LABEL="ceph_tune_end"

    Commandes d’Application Immédiate (Crucial à refaire)

    Il est OBLIGATOIRE de recharger les règles UDEV pour appliquer le correctif :

    udevadm control --reload-rules udevadm trigger

    Validation des Changements UDEV

    Vérifiez les nouveaux paramètres appliqués sur vos OSDs. La valeur de rq_affinity doit être 0.

    cat /sys/block/sda/queue/scheduler cat /sys/block/sdd/queue/scheduler cat /sys/block/sda/queue/nr_requests cat /sys/block/sdd/queue/read_ahead_kb cat /sys/block/sda/queue/rq_affinity

    Résultats attendus : none (scheduler), 256 (nr_requests), 4096 (read_ahead_kb), et 0 (rq_affinity)

    3. Étape 3 : Configuration de la Tolérance Ceph (ceph.conf & BlueStore)

    Modification du Fichier : /etc/ceph/ceph.conf

    Ces options augmentent la tolérance de Ceph aux latences temporaires (crucial pour l’USB). Elles empêchent les OSDs de se déclarer « en panne » trop rapidement, réduisant les erreurs de *slow ops*.

    Contenu à Ajouter à la section [osd]

    [osd]
# Augmente le temps avant qu'une opération threadée ne timeout (valeur par défaut : 10)
osd_op_thread_timeout = 30 
# Augmente le temps avant qu'un thread OSD ne soit considéré comme bloqué (valeur par défaut : 30)
osd_op_thread_suicide_timeout = 60
# Augmente la grâce pour le heartbeat (valeur par défaut : 20)
osd_heartbeat_grace = 60

    Commandes d’Optimisation BlueStore (Très Important)

    Ces commandes sont essentielles pour permettre à BlueStore de masquer la latence en augmentant les limites d’octets et en désactivant la limitation basée sur le nombre d’opérations :

    ceph config set global bluestore_throttle_deferred_bytes 536870912 ceph config set global bluestore_throttle_bytes 268435456 ceph config set global bluestore_throttle_cost_per_io 0

    Limite de données différées (512 Mo), limite de données en vol (256 Mo), et désactivation du coût par I/O.

    Commandes d’Application

    Ces changements nécessitent un redémarrage des démons OSD sur ce nœud pour être pris en compte :

    systemctl restart ceph-osd.target

    Validation de l’État Ceph

    Vérifiez le statut du cluster (attendre que les OSDs reviennent in et up) :

    ceph -s

    4. Étape 4 : Tests et Surveillance des Performances

    Après avoir appliqué toutes les modifications (y compris le correctif UDEV et le tuning BlueStore), l’indicateur principal de succès est la réduction significative des messages d’erreur de lenteur. Voici comment vérifier.

    A. Surveillance des *Slow Operations*

    C’est le test le plus direct. Vous devriez voir ce compteur rester à zéro ou devenir très faible, même en période de charge.

    Commande :

    ceph health detail

    **Résultat attendu :** Réduction ou disparition des avertissements OSD_SLOW_OPS.

    B. Vérification de la Latence des OSDs

    Cette commande affiche les latences des opérations pour chaque OSD. C’est le moyen de comparer l’impact des optimisations sur vos deux disques.

    Commande :

    ceph osd perf

    **Interprétation :** L’objectif est de voir la latence de l’OSD USB revenir à un niveau stable, même s’il reste supérieur au SATA. Le tuning BlueStore devrait aider à lisser les pics de latence.

    C. Surveillance des Logs

    Surveillez les logs pendant une charge de travail pour vous assurer que les messages d’erreur critiques (timeouts, OSD down) ne réapparaissent pas.

    Commande :

    tail -f /var/log/ceph/ceph.log

    Si la log est plus silencieuse concernant les OSDs lents après ces étapes, l’optimisation est réussie. Concentrez-vous sur l’absence de *timeouts* et de messages clog.

    Ces étapes d’optimisation représentent la configuration logicielle maximale pour stabiliser les OSDs sur ces types de connexions non natives.