Overblog
Suivre ce blog Administration + Créer mon blog
1 décembre 2009 2 01 /12 /décembre /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.

Partager cet article
1 décembre 2009 2 01 /12 /décembre /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...

Partager cet article
3 novembre 2008 1 03 /11 /novembre /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...

Partager cet article
24 octobre 2008 5 24 /10 /octobre /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.

 

 

Partager cet article
17 octobre 2008 5 17 /10 /octobre /2008 13:00

 

Après une longue période d'inactivité, je me décide enfin à publier une série d'article dont un sur la modification d'un miniroot Solaris 10x86. Je modifie le miniroot pour plusieurs raisons que vous comprendrez par la suite. Mais avant tout commençons par le miniroot

 

Le miniroot Solaris 10x86 n'est ni plus ni moins qu'un fichier compressé. Nommé miniroot.x86, il est disponible sur toutes les images de Solaris (Opensolaris y compris). La taille du fichier étant fixe, toute modification y est impossible sans quelques modifications. Vous trouverez ci dessous une méthode pour le modifier.

 

Pour modifier un miniroot Solaris 10x86, il faut au préalable :

  • Créer un fichier
  • Monter ce fichier comme étant un système de fichiers
  • Formater ce système de fichiers
  • Recopier le contenu de l'ancien miniroot dans le système de fichiers

 

La commande mkfile permet de créer un fichier en lui indiquant une taille spécifique. Cette taille doit être calculée de la manière suivante : taille actuelle du miniroot + taille des modification à y inclure

 

# pwd
/tmp
# mkdir /image-new /image-old
# gzcat x86.miniroot > x86.miniroot.img.old
# ls -lh x86.miniroot.img.old
-rw-r--r--     1 root     root         290M  /tmp/x86.miniroot.img.old

 

Les modifications seront inférieures à 5 Mo mais bon on va être large.

 

# mkfile 300m x86.miniroot.img.new

 

10 Mo c'est large non ?


# lofiadm -a /tmp/x86.miniroot.img.new
/dev/lofi/1
# newfs /dev/rlofi/1
# mount /dev/lofi/1 /image-new
# lofiadm -a /tmp/x86.miniroot.img.old
/dev/lofi/2
# mount /dev/lofi/2 /image-old
# cd /image-old
# find . -print | cpio -mpdv /image-new
# cd /tmp
# umount /image-old
# lofiadm -d /tmp/x86.miniroot.img.old
# cd /image-new

 

Les modifications sont alors possibles dans le système de fichiers /image-new (si celles-ci sont inférieurs à 10 Mo). Une fois les modifications effectuées ont termine le miniroot.

 

# pwd
/image-new
# cd /tmp
# umount /image-new
# lofiadm -d /tmp/x86.miniroot.img.new
# gzip /tmp/x86.miniroot.img.new
# mv /tmp/x86.miniroot.img.new.gz /tmp/x86.miniroot

 

Rien de bien méchant non ?

 

Partager cet article
9 avril 2008 3 09 /04 /avril /2008 22:21

 

Si vous gérez de nombreuses bases de données et que vous êtes en Solaris 10, il est souvent nécessaire de mettre en place des projects pour l'allocation des ressources systèmes IPC. Vous trouverez ci dessous une petite explication pour configurer et vérifier le paramétrage des projets Solaris avec vos bases de données.

 

En solaris 10, la gestion de certaines ressources systèmes (notamment les IPC) sont gérés par des project. Si vous administrez des serveurs comportant plusieurs bases de données (type oracle) voiçi comment gérer un seul project pour plusieurs utilisateurs ayant un groupe primaire commun.

 

Quelques mots sur les "projects" : par convention, seul les utilisateurs sont autorisés à utiliser les projects. Lors de la connexion d'un utilisateur, un "project" par défaut lui est assigné "pam_unix_cred.so.1". Pour plus de détail, il est possible de se référer à la page de manuel getprojent(3PROJECT) concernant l'appel getdefaultproj().

 

L'attribution d'un projet à un utilisateur s'applique dans l'ordre suivant :

  • Si le "project" spécifie l'utilisateur et si le fichier user_attr est correctement renseigné
  • Si le fichier "project" contient l'entrée user.<user_name>
  • Si le fichier "project" contient l'entrée group.<groupe_name>

 

Attention, les "projects" gérés à l'aide de groupe fonctionnent exclusivement pour des groupes primaires (ne fonctionne pas avec les groupes secondaires).

 

Vérification des utilisateurs

 

# egrep userora00 /etc/passwd
userora00:x:300:35:userora1:/oracle/ora00:/usr/bin/csh
userora01:x:301:35:userora1:/oracle/ora01:/usr/bin/csh
userora02:x:302:35:userora1:/oracle/ora02:/usr/bin/csh

 

Vérification du groupe

 

# egrep 35 /etc/group
dba:*:35:

 

Visualisation du "project" pour le groupe dba

 

# projects -l group.dba
group.dba
        projid : 100
        comment: "ORACLE"
        users  : (none)
        groups : (none)
        attribs: process.max-sem-nsems=(priv,2048,deny)
                  project.max-sem-ids=(priv,4096,deny)
                  project.max-shm-ids=(priv,256,deny)
                  project.max-shm-memory=(priv,4294967296,deny)

 

Vérification de l'allocation des ressources

 

# su - userora00
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
maya%
maya% id -a
uid=300(userora00) gid=9003(dba) groups=9003(dba)

maya% projects
default group.dba

maya% prctl -P $$ | egrep project.max-shm-memory
project.max-shm-memory privileged 4294967296 - deny -
...

 

La configuration est correctement positionnée pour l'utilisateur userora00 (ici on ne vérifie que la valeur de la SHM). Comprendre et administrer ce type de fonctionnalité est indispensable sous Solaris 10. Cela vous permet de garantir le bon fonctionnement de vos applications.

 

Partager cet article
17 mars 2008 1 17 /03 /mars /2008 21:58

 

Sans rentrer dans les détails conernant la configuration du firewall dans Solaris 10, cette article va vous permettre de configurer  ipfilter dans le cas  ou une configuration ipmp est déjà présente. Les détails se trouvent ci-dessous :

 

Configuration ipmp

 

Soit un serveur solaris type V40z avec deux interfaces type bge.

 

# cat /etc/hostname.bge0
host01 deprecated -failover netmask + broadcast + group ipmp1
addif host netmask + broadcast + up

# cat /etc/hostname.bge1
host02 deprecated -failover netmask + broadcast + group ipmp1

# cat /etc/inet/hosts
...
192.168.1.10   host host.domain.com   loghost
192.168.1.11   host01 host01.domain.com
192.168.1.12   host02 host02.domain.com

 

Configuration ipfilter

 

Cas Solaris  10  update  2

 

Pour configurer ipfilter avec l'ipmp, il faut utiliser le driver pfil.

 

# cat /etc/ipf/pfil.ap
...
#e1000g   -1    0    pfil
bge       -1    0    pfil
...

 

La modification du fichier /etc/ipf/pfil.ap nécessite un arrêt/relance du module (ou plus simplement du serveur). Il ne faut pas oublier d'activer le service smf.

 

# svcs  online svc:/network/pfil:default
# svcs  svc:/network/pfil:default
STATE          STIME    FMRI
online         Oct_03   svc:/network/pfil:default

 

Il faut créer un groupe (nommé ici ipmp1, tout comme le nom du groupe ipmp) et lui assigner les deux cartes réseaux.

 

# ndd -get /dev/pfil qif_ipmp_set ipmp1=bge0,bge1

 

La vérification s'effectue de cette façon


# ndd -get /dev/pfil qif_ipmp_status
ifname members
ipmp1 bge0,bge1

# ndd -get /dev/pfil qif_status
ifname ill q OTHERQ ipmp num sap hl nr nw bad copy copyfail drop notip nodata notdata
ipmp1 0 0 0 0 0 800 0 0 0 0 0 0 0 0 0 0
QIF3 0 ffffffff882e7050 ffffffff882e7148 0 3 806 0 1633203 106184 0 0 0 0 0 0 0
bge1 ffffffff88121540 ffffffff8824d568 ffffffff8824d660 ffffffff9e14c580 2 800 14 9627709772 18921021835 0 3638 0 3638 0 0 0
QIF1 0 ffffffff8824f7f0 ffffffff8824f8e8 0 1 806 0 0 17 0 0 0 0 0 0 0
bge0 ffffffff880ad1c0 ffffffff8814d7e8 ffffffff8814d8e0 ffffffff9e14c580 0 800 14 0 0 0 0 0 0 0 0 0

 

Pour visulaliser toutes les options du driver pfil

 

# ndd -get /dev/pfil ?

?                        (read only)
pfildebug                (read and write)
pfil_delayed_copy        (read and write)
pfil_interface           (read only)
qif_status               (read only)
sill_status              (read only)
qif_ipmp_status          (read only)
qif_ipmp_set             (write only)
qif_verbose              (read and write)
pfil_inet4               (read only)
pfil_inet6               (read only)
pfil_sync                (read only)

 

Cas Solaris  10  update  3


Le driver pfil n'existe plus à partir de l'update 3 de Solaris 10. Il faut utilisé l'option ipmp_hook_emulation du driver ip.

 

# ndd -get /dev/ip ipmp_hook_emulation
0
# ndd -set /dev/ip ipmp_hook_emulation 1
# ndd -get /dev/ip ipmp_hook_emulation
1

 

Validation dans ipfilter

Les règles du firewall doivent contenir le nom du groupe ipmp (attention dans le cas de Solaris 10 update 2 c'est le nom du groupe pfil qu'il faut indiquer). Le démon ipmon doit être lancés pour visualiser les logs

 

# tail -f /var/adm/ipfilter.log

12/03/2008 08:48:27.432715 ipmp1 @0:117 b 192.168.1.10,3200 -> 192.168.1.100,4976 PR tcp len 20 40 -R OUT
12/03/2008 08:48:29.444544 ipmp1 @0:117 b 192.168.1.10,3200 -> 192.168.1.100,4976 PR tcp len 20 40 -R OUT
12/03/2008 08:48:33.468254 ipmp1 @0:117 b 192.168.1.10,3200 -> 192.168.1.100,4976 PR tcp len 20 40 -R OUT
12/03/2008 08:48:41.515359 ipmp1 @0:117 b 192.168.1.10,3200 -> 192.168.1.100,4976 PR tcp len 20 40 -R OUT


Partager cet article
17 mars 2008 1 17 /03 /mars /2008 18:18

 

Ce blog va aborder l'administration système pour l'Unix Solaris. Ne trouvant pratiquement aucun site Internet (en Français) abordant ce thème je vais essayer d'y remedier un minimum.

 

A très bien tôt pour les premiers articles....

Partager cet article