Samedi 5 décembre 2009
6
05
/12
/Déc
/2009 22:33
Voilà qu'un beau matin, une node d'un cluster Oracle RAC décide de se tuer. Voiçi l'analyse postmortem qui a permis de détecter un problème de désynchronisation d'horloge (TOD & tick). On
commence par ici ...
# cd /var/core/`hostname`
# file *.0
unix.0: ELF
64-bit MSB executable SPARCV9 Version 1, UltraSPARC1 Extensions Required, statically linked, not stripped, no debugging information available
vmcore.0: SunOS 5.10 Generic_127127-11 64-bit SPARC crash dump from 'xxxxxx'
# mdb unix.0 vmcore.0
Loading modules: [ unix krtld
genunix specfs dtrace ufs sd mpt px ssd fcp fctl md ip hook neti sctp arp usba zfs random ipc nfs sppp crypto cpc fcip logindmux ptm ]
>
>
::panicinfo
cpu
17
thread
30009bf86c0
message forced crash dump initiated at user
request
tstate
4400001600
g1
b
g2
0
g3
11ca714
g4
6e0
g5 88000000
g6 0
g7 30009bf86c0
o0 1211a68
o1 2a100a9b9e8
o2
1
o3 0
o4 fffffffffffffff5
o5 1000
o6 2a100a9b0b1
o7 1068368
pc 104980c
npc 1049810
y 0
>
30009bf86c0::thread -p
ADDR
PROC LWP CRED
0000030009bf86c0 600b7cb50b8 600bab9af30
6009a003d98
>
600b7cb50b8::ps -ft
S PID PPID PGID SID
UID FLAGS ADDR NAME
R
29139 28993 1772 1772 0 0x4a004000 00000600b7cb50b8 /crs/10.2.0/bin/oprocd.bin run -t 1000 -m 500 -f
T 0x30009bf86c0 <TS_ONPROC>
> 600b7cb50b8::walk thread |::findstack
stack pointer for thread 30009bf86c0: 2a100a9b0b1
000002a100a9b161 kadmin+0x4a4()
000002a100a9b221 uadmin+0x11c()
000002a100a9b2e1 syscall_trap+0xac()
Le démon opcrod est à l'origine du suicide de la node (commande uadmin). Pour rappel le démon oprocd surveille le cluster RAC et réalise le fencing du cluster RAC (isolement primitif d'un noeud
lors d'une défaillance de celui-ci). Lors de ce fencing, oprocd effectue des vérifications de fonctionnement, puis se fige. Si le réveil de l’oprocd n’a pas lieu avant une durée configurée,
celui-ci procède au redémarrage du noeud du cluster.
Après une petite recherche, il s'agit d'un problème de TOD : bug suivant 6595936. L'ajout des deux
paramètres suivants dans le fichier system a permis de corriger le problème définitivement.
# cat /etc/system
...
* Bug ID 6595936
set tod_broken = 1
set dosynctodr = 0
..
Par gloumps
-
Publié dans : kernel
0
Mardi 1 décembre 2009
2
01
/12
/Déc
/2009 23:04
Amélioration du script Dtrace sig.d, pour permettre d'afficher un plus grand nombre d'informations. Ca ressemble à cela :
#!/usr/sbin/dtrace -qs
proc:::signal-send
{
printf("%Y %s(pid:%d uid:%d) is sending signal %d to %s\
(pid:%d ppid:%d uid:%d)\n", walltimestamp,execname,\
pid,uid,args[2],args[1]->pr_fname,args[1]->pr_pid,\
args[1]->pr_ppid,args[1]->pr_uid);
}
Pas très compliqué à faire... Ce petit script Dtrace m'a permis de prouver que l'arrêt brutale d'une application ne provenait pas du système mais de l'application elle-même.
Par gloumps
-
Publié dans : dtrace
0
Mardi 1 décembre 2009
2
01
/12
/Déc
/2009 22:45
Comme savoir si l'on utilise correctement les appels "directio" ? Avec un petit script Dtrace, il est possible de visualiser facilement les appels systèmes et ansi vérifier correctement ce que
fait Solaris. Ci-joint le petit script D qu'il suffit de modifier au besoin...
#!/usr/sbin/dtrace -s
#pragma D option flowindent
fbt:ufs:ufs_directio_read:entry
/pid == $1/
{
self->ts[probefunc] = timestamp;
}
fbt:ufs:ufs_directio_read:return
/pid == $1 && self->ts[probefunc] != 0/
{
self->duration[probefunc] = (timestamp - self->ts[probefunc])/1000;
}
fbt:ufs:ufs_directio_read:
/pid == $1/
{
trace(self->duration[probefunc]);
self->duration[probefunc] = 0;
}
Bien entendu, il y a plusieurs façon de faire. Merci de me l'indiquer, je suis preneur.
Par gloumps
-
Publié dans : dtrace
0
Mardi 1 décembre 2009
2
01
/12
/Déc
/2009 22:23
Une petite publication pour mettre en évidence les méthodes d'installation réseau (sous GRUB notamment) d' un système Solaris 10x86. Bonne lecture...
Par gloumps
-
Publié dans : administration
0
Lundi 3 novembre 2008
1
03
/11
/Nov
/2008 14:21
Petite procédure pour générer une image iso bootable pour Solaris 10x86 (en se basant sur GRUB). Cette article va permettre de mieux comprendre le processus d'installation réseau de Solaris 10x86
avec GRUB (sans PXE). On commence doucement par ici...
Par gloumps
-
Publié dans : administration
1
Vendredi 24 octobre 2008
5
24
/10
/Oct
/2008 16:52
Cela restera à jamais gravé dans ma mémoire. Suite à un ajout de volumétrie dans un diskgroup, la ressource HAS du cluster n'a pas pu s'activer correctement sur aucune des nodes. Le message à
la console était clair "diskgroup : no valid configuration copies". Je suis passé des cris aux larmes : il s'agissait d'un cluster de prod (instance SAP de 3 To avec 120 sapdatas). J'ai
retroussé mes manches, et j'ai appliqué la procédure. C'est simple dans la théorie mais très stressant dans la pratique.... en tout cas c'est expliqué en dessous...
Pour qu'un diskgroup VxVM soit importé sur un serveur, il est nécessaire que son nombre de copie soit valide. Dans le cas contraire le diskgroup ne peut importé. Cela ne veut pas dire que les
données soient perdues mais que la structure VxVM est invalide. La méthode suivante permet de reconstruire un diskgroup VxVM (sans perte des données physiques... enfin normalement).
Avant de commencer, il est nécessaire de posséder une sauvegarde de la structure. Pour la récupérer il faut l'enregistrer dans un fichier (le mieux est de la sauvegarder régulièrement via un
script exécuté par la cron).
Sauvegarde de la structure VxVM
# vxdisk list
DEVICE
TYPE DISK GROUP STATUS
c0t0d0s2 auto:sliced disk1
zonesdg online
c0t1d0s2 auto:sliced disk2
zonesdg online
c0t2d0s2 auto:sliced disk3
zonesdg online
c0t3d0s2 auto:sliced disk4
zonesdg online
c0t4d0s2 auto:sliced disk5
zonesdg online
c0t5d0s2 auto:sliced rootdisk rootdg
online
c1t0d0s2 auto:sliced mir1
zonesdg online
c1t1d0s2 auto:sliced mir2
zonesdg online
c1t2d0s2 auto:sliced mir3
zonesdg online
c1t3d0s2 auto:sliced mir4
zonesdg online
c1t4d0s2 auto:sliced mir5
zonesdg online
c1t5d0s2 auto:sliced rootmir rootdg
online
c3t0d0s2 auto:sliced rootalt rootdg
online
# vxdisk list c0t0d0
...
config priv 000017-000247[000231]: copy=01 offset=000000 enabled
config priv 000249-007310[007062]: copy=01 offset=000231 enabled
log priv 007311-008415[001105]: copy=01 offset=000000 enabled
...
# /etc/vx/diag.d/vxprivutil list /dev/rdsk/c0t0d0s3
config priv 000017-000247[000231]: copy=01 offset=000000 enabled
config priv 000249-007310[007062]: copy=01 offset=000231 enabled
log priv 007311-008415[001105]: copy=01 offset=000000 enabled
La structure VxVM est bien présente sur ce disque (config enabled). La sauvegarde est alors possible.
# /etc/vx/diag.d/vxprivutil dumpconfig /dev/rdsk/c0t0d0s3 > /tmp/zonesdg
Si vous prévérerz sauvegarder la config régulièrement ci-joint un petit script à
faire exécuter par la cron.
Réinitialisation des disques
On recherche l'ensemble des disques appartenants au diskgroup (attention au éventuelle duplication dans le fichier /tmp/zonesdg pour les volumes et les plexes : si nécessaire les supprimer
ou rejouer la sauvegarde de la structure).
# cat /tmp/zonesdg | vxprint -D - -md | /usr/xpg4/bin/grep -e "^dm" -e "last_da_name" >
/tmp/disklist
La liste des disques générées correspond dans notre cas à :
dm disk1
last_da_name=c0t0d0s2
dm disk2
last_da_name=c0t1d0s2
dm disk3
last_da_name=c0t2d0s2
dm disk4
last_da_name=c0t3d0s2
dm disk5
last_da_name=c0t4d0s2
dm mir1
last_da_name=c1t0d0s2
dm mir2
last_da_name=c1t1d0s2
dm mir3
last_da_name=c1t2d0s2
dm mir4
last_da_name=c1t3d0s2
dm mir5
last_da_name=c1t4d0s2
Une fois la liste obtenu il faut réinitialiser les disques (attention à la taille de la private). Il est impératif que les disques que l'on initialise soit les mêmes disques physiques
(attention au changement de contrôlleurs si reboot).
# ksh
# for disk in $(cat /var/tmp/disks)
do
/etc/vx/bin/vxdisksetup -i $disk
done
Création du diskgroup et ajout des disques au diskgroup
Une fois les disques initialisés il faut recréer le diskgroup et y inclure les disques. Il est impératif que les noms dm correspondent bien au disques physiques.
# vxdg init zonesdg disk1=c0t0d0s2
# vxdg -g zonesdg adddisk disk2=c0t1d0s2
# vxdg -g zonesdg adddisk disk3=c0t2d0s2
...
# vxdg -g zonesdg adddisk mir5=c1t4d0s2
Recopie de la structure VxVM
Si les disques phydiques intégrés au diskgroup sont bon et que les noms dm correspondent bien au bon disque physiques alors la configuration VxVM peut être reclaquée.
# cat /tmp/zonesdg | vxprint -D - -hmvps > /tmp/vxmakefile
# vxmake -g zonesdg -d /tmp/vxmakefile
Activation des volumes
# vxrecover -g zonesdg -s -b
# ksh
# for vol in $(vxprint -q -g zonesdg -v | awk '{print $2}')
do
vxvol -g zonesdg -f start $vol
done
Normalement, il suffit de faire un check (fsck) sur les systèmes de fichiers (pour être sur) puis de les monter.
Par gloumps
-
Publié dans : lvm
0
