6 votes

Buster Debian : Comment démarrer ZFS apr�s open-iscsi dans systemd ?

J'ai installé Debian 10 (Buster) et j'ai ajouté ZFS à partir de Backports. J'ai 4 iSCSI-LUNs que j'utilise comme disques pour ZFS. Chaque LUN contient un zpool séparé.

Jusqu'à présent, la configuration ZFS fonctionne. Mais le système n'est pas stable au redémarrage. Parfois, après le redémarrage, tous les volumes ZFS sont restaurés et montés correctement, parfois non. Je pense que cela se produit parce que ZFS n'attend pas la fin du processus iSCSI.

J'ai essayé :

$ cat /etc/systemd/system/zfs-import-cache.d/after-open-iscsi.conf

[Unit]
After=open-iscsi.service
BindsTo=open-iscsi.service

$ systemd-analyze critical-chain zfs-import-cache.service

The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

zfs-import-cache.service +1.602s
open-iscsi.service @2min 1.033s +286ms
  iscsid.service @538ms +72ms
    network-online.target @536ms
      ifup@eth0.service @2min 846ms
        apparmor.service @2min 748ms +83ms
          local-fs.target @2min 745ms
            exports-kanzlei.mount @2min 3.039s
              local-fs-pre.target @569ms
                keyboard-setup.service @350ms +216ms
                  systemd-journald.socket @347ms
                    system.slice @297ms
                      -.slice @297ms

Cela ne résout pas mes problèmes. Probablement que le matériel iSCSI n'est pas prêt mais déjà activé par le système et donc ZFS ne trouve pas ses périphériques.

Actuellement, la seule solution de contournement très sale est de mettre des règles dans /etc/rc.local :

systemctl start zfs-import-cache.service
systemctl start zfs-mount.service
systemctl start zfs-share.service
systemctl start zfs-zed.service

zfs mount -a

Cela fonctionne, mais je veux une solution propre.

Ce que je ne comprends vraiment pas et ce qui me rend fou, c'est que dans Debian, il existe /etc/init.d/scriptname et aussi systemd dossiers de l'unité. Lequel est utilisé ? sysvinit ou systemd ? Pourquoi les deux sont fournis ? Lesquels sont les meilleurs ?

Donc, actuellement, j'ai l'impression que le processus de démarrage n'est pas stable.

0 votes

C'est exactement la question que je me pose actuellement. Je ne trouve pas de solution recommandée pour cela. Le manuel systemd fournit suffisamment d'informations pour que je puisse concevoir des tentatives de solutions, mais ce que j'ai essayé jusqu'à présent ne fonctionne pas. Si vous avez trouvé une solution, veuillez poster votre réponse.

0voto

cosimo Points 1037

La méthode recommandée pour ce faire est probablement d'utiliser un fichier udev règle, mais je ne sais pas udev bien assez. Voici ma solution actuelle (veuillez me dire comment faire mieux) :

  1. Créez un service pour le périphérique disque iSCSI sur lequel vous devez attendre ( /dev/sdb1 dans mon cas) :

    $ sudo EDITOR=vim systemctl edit --force --full dev-sdb1.service

  2. Dans la définition du service, faites en sorte que ZFS en dépende.

  3. Dans la définition du service, faites-lui attendre que l'appareil soit disponible.

3 est la partie délicate. Voici ce que j'ai :

[Unit]
Description="Monitor the existence of /dev/sdb1"
Before=zfs-import-cache.service
# Requires=dev-sdb1.device
# After=dev-sdb1.device
# I thought this would wait for the device to become available.
# It doesn't, and there appears to be no way to actually do so.

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'while [ ! -e /dev/sdb1 ]; do sleep 10; done'
# pathetic

[Install]
WantedBy=multi-user.target
RequiredBy=zfs-import-cache.service 

Évidemment, il serait préférable de le faire sans un Shell Shell pour interroger le périphérique. Après avoir lu la documentation concernant les unités de périphérique et les réponses à ces questions Stack Exchange :

et vérifié que dev-sdb1.device existe après le démarrage, je m'attendais à pouvoir simplement faire le zfs-import-cache.service attendre /dev/sdb1 en ajoutant les règles

After=dev-sdb1.device
Requires=dev-sdb1.device

à sa définition. Cela ne fonctionne pas ; il dira le service failed with result 'dependency' quoi que cela veuille dire. Je suppose que le dev-sdb1.device n'existe pas encore, systemd ne sait pas qu'il sera bientôt créé, et je ne trouve pas de directive disant "attendez-le".

Autres approches possibles :

  1. Utilisez une unité de chemin au lieu d'un Shell Shell pour attendre le périphérique. Je n'ai pas essayé ceci.
  2. Ajouter un udev adaptation des règles /dev/sdb o /dev/sdb1 (si possible) pour rendre explicitement son unité de dispositif disponible . Je n'ai pas essayé ; je ne vois pas pourquoi cela serait utile (l'unité de périphérique est déjà créée) et je ne sais pas comment déterminer si cela aurait d'autres effets sur l'initialisation du périphérique et casserait quelque chose en conséquence.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X