Blog

Bienvenue...

...sur mon blog, j'utilise ce site pour noter les petites choses qui me sont utiles, que ça soit informatique ou autre :)

Il y a 4 années 2 mois

Le truc a la con du jour, mes VMs ne montent pas les points de montages NFS au boot...

Du coup, notamment pas de backup (j'ai un point de montage sur le NAS qui me permet de centraliser les backups des machines).

...relou, donc j'ai pas mal cherché sur le net, au début je pensais que c'était un problème de route, car mon NAS ayant deux interfaces réseaux, donc deux IPs, je n'ai autorisé le protocole NFS que sur une seule des deux interfaces, en fait c'est surtout que l'autre interface est dédiée au trafic iSCSI pour l'ESX.

Donc au début je pensais à un problème de route, les VMs ayant deux IPs, je pensais que le montage NFS ne passait pas par la bonne iface... bref j'ai donc ajouté des routes statiques :

Super simple sur la debian, il suffit de créer un fichier dans le répertoire "/etc/network/if-up.d" :

/etc/network/if-up.d/000routesupernas
#!/bin/sh
if [ "$IFACE" = "eth0" ]; then
  route add -net <IP DU NAS> netmask 255.255.255.255 gw <IP DE LA CARTE LOCALE> dev eth0
fi

J'ai aussi renommé le fichier avec 000 devant, histoire que le script s’exécute dans les premiers, je ne sais pas si cela a vraiment un effet (j'ai remarqué que "resolvconf" est nommé comme cela, donc...).

Pour faire les choses bien, j'ai créé le pendant dans "/etc/network/if-down.d" :

/etc/network/if-down.d/routesupernas
#!/bin/sh
if [ "$IFACE" = "eth0" ]; then
  route del -net <IP DU NAS> netmask 255.255.255.255 gw <IP DE LA CARTE LOCALE> dev eth0
fi

Bref, après maint redémarrage de la machine, je n'arrivait pas a trouver de solution, mes points de montage n'étaient tjs pas monté au boot...

J'ai trouvé sur le net un thread expliquant qu'il fallait supprimer le répertoire "/var/run/network/mountnfs" lorsque les points de montage n'étaient pas montés, j'ai même créé un script dans "/etc/network/if-down.d/" :

/etc/network/if-down.d/mountnfs
#!/bin/sh
if [ -d /var/run/network/mountnfs ]; then
  rm -Rf /var/run/network/mountnfs
fi

...reboot... toujours rien, j'ai encore fait quelques recherches et suit tombé sur l'option "_netdev" et là MAGIE !! ça marche :P

/etc/fstab
<IP DU NAS>:/volume1/photo      /home/share/photoz      nfs     defaults,user,auto,noatime,intr,rsize=8192,wsize=8192,_netdev   0       0

Donc bref, il suffit d'ajouter cette petite option, qui spécifie que le point de montage doit être traité APRES démarrage du réseau...

Après l'ultime reboot, j'ai donc :

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/turnkey-root
                       17G  1,6G   15G  10% /
tmpfs                 251M     0  251M   0% /lib/init/rw
udev                  246M  100K  246M   1% /dev
tmpfs                 251M     0  251M   0% /dev/shm
/dev/sda1             473M   17M  433M   4% /boot
<IP DU NAS>:/volume1/backup
                      2,7T  819G  1,9T  30% /home/share/backup

YOU WIN \o/

Il y a 4 années 4 mois

Les packages à installer : libpam-ldap et libnss-ldapd...

Pour libnss il faut choisir a minima les NSS passwd/group et shadow

...faut que je fasse un tuto plus explicite ;)

Commande pour tester une fois la conf. effectuée :

getent <group|passwd|shadow>
Il y a 4 années 8 mois

Dans le cadre de la mise en place d'un QM multi-instance, nous avions une manip à faire sur un des serveurs, (ajout d'un vCPU, donc redémarrage de la VM).

Du coup j'explique à l'exploitant qu'il peut switcher l'instance active vers le QM en standby, faire ses manips, relancer la VM, le QM et faire la même manip sur la 2eme VM. Tout ça afin de maintenir le service actif...

Bref, donc la commande à lancer pour arrêter une instance de QM est la suivante :

endmqm -s <QM NAME>

Ce qui fait basculer le QM s'il est actif sur une instance standby.

Sauf que quand j'essayais de faire la manip, j'obtenais le message en titre (AMQ7276 : WebSphere [...]).

Je me suis donc mis à rechercher une soluce... google est mon ami, et mqseries.net aussi :P

...ben oui si tu veux switcher, il faut que le QM de l'autre côté soit en standby, sinon ça switch pas \o/

strmqm -x <QM NAME>
Il y a 6 années 11 mois

...sur mon blog, j'utilise ce site pour noter les petites choses qui me sont utiles, que ça soit informatique ou autre :)

Il y a 6 années 11 mois

Une bonne pratique est de nommer les XmitQ du nom du QM de destination.

Ok, mais encore, quel intérêt ? Cela permet en fait d'effectuer un routage des messages plus "fluide" en utilisant les champs ReplyTo des messages.

Lorsqu'on répond à un message MQ (en passant par l'API C ou la lib java spécifique WMQ - je n'ai pas regardé s'il existait un équivalent en JMS) le QM put en fait le message dans la XmitQ ayant le nom du QM spécifié dans le champ ReplyToQM du message MQ.

Le message remonte alors vers le QM de destination. Que se passe t il lorsque l'on est en architecture étoile (un QM central et n QM magasins rattachés à ce central) et qu'on essaye de répondre à un message envoyé à un magasin mais d'un QM connu uniquement du central ?

En effet, si vous m'avez suivi et que vous connaissez un peu le comportement d'un QM, la XmitQ étant inconnue du QM Magasin, le message échoue fatalement dans la Dead Letter Queue (la file des messages que le QM ne sait pas router).

Il faut donc positionner au niveau du QM Magasin une "Default XMITQ" pointant vers le central, le QM Magasin routera alors le message vers cette XmitQ et le QM Central, qui connait le ReplyToQMGR, saura dans laquelle de ses XmitQ il doit mettre le message.

Pages