Solaris mon amour

précédent 1 2 3 4 5 6 7 8 9 suivant fin

Jeudi 7 février 2013 4 07 /02 /Fév /2013 20:41

Observations : analyse d'un core "...Unable to fork..."

Les apparences sont quelques fois trompeuses… Petite démonstration confirmant cet adage.

Situons le contexte : plusieurs DBA Oracle nous remontent un incident sur un de leur serveur. Le symptôme étant le suivant : connexion impossible. Après une rapide vérification le diagnostic initiale semble être le bon. Petite connexion au déport console du serveur et me voilà devant un message des plus explicite « Unable to fork ». Hop, je provoque un petit panic et en avant pour une petite analyse.

Avant de me lancer tête baissée dans l’analyse du core, je m’intéresse aux logs du serveur en recherchant le pattern fork.

Jan 22 13:05:43 myserver sshd[7716]: [ID 800047 auth.error] error: fork: Error 0
Jan 22 13:08:06 myserver inetd[7805]: [ID 702911 daemon.error] Unable to fork inetd_start method of instance svc:/network/nrpe/tcp:default: Resource temporarily unavailable
Jan 22 13:08:36 eqds2dstdby002 last message repeated 1 time
Jan 22 13:09:59 myserver inetd[7805]: [ID 702911 daemon.error] Unable to fork inetd_start method of instance svc:/network/nrpe/tcp:default: Resource temporarily unavailable

A partir de 13:05, il semble que le serveur ne pouvait plus « forker » de nouveau process. Je vais faire parler le core !?

# cd /var/crash/myserver
# savecore –f vmdump.0
savecore -f vmdump.0
savecore: System dump time: Tue Jan 22 14:54:46 2013

savecore: saving system crash dump in /var/crash/myserver/{unix,vmcore}.0
Constructing namelist /var/crash/myserver/unix.0
Constructing corefile /var/crash/myserver/vmcore.0
8:36 92% done
9:22 100% done: 3571069 of 3571069 pages saved

# mdb –k 0
Loading modules: [ unix genunix specfs dtrace zfs sd mpt px ssd fcp fctl sockfs ip hook neti qlc dls sctp arp usba md cpc fcip random crypto logindmux ptm ufs sppp ipc nfs lofs ]
> fork_fail_pending/D
fork_fail_pending:
fork_fail_pending: 1

Il s’agit bien d’un problème de fork. Combien de processus généré ?

> ::ps !grep -v FLAGS | wc -l
29952

29952 processus en machine !! Sachant que la limite haute se situe vers 30000, je comprends mieux le problème. Essayons dans savoir plus. Quel est le contributeur ? S’agit-il d’une « mauvaise bouche » dans un script (merci la fork bomb) ?

> ::ps
S PID PPID PGID SID UID FLAGS ADDR NAME
R 0 0 0 0 0 0x00000001 00000000018b09c0 sched
R 4510 0 0 0 0 0x00020001 00000600e4766018 zpool-oradg00
R 92 0 0 0 0 0x00020001 00000600b4821960 zpool-spool
R 88 0 0 0 0 0x00020001 00000600b4823290 zpool-dump
R 86 0 0 0 0 0x00020001 00000600b21b6ca8 zpool-asmdg00
R 7 0 0 0 0 0x00020001 00000600b21b9270 vmtasks
R 3 0 0 0 0 0x00020001 000006009bdb4008 fsflush
R 2 0 0 0 0 0x00020001 000006009bdb4ca0 pageout
Z 1 0 0 0 0 0x4a004000 000006009bdb5938 init
Z 4712 1 11 11 0 0x5a006002 0000060146e6c0d0 p_ctscd
Z 4713 1 11 11 0 0x5a006002 0000060153fa8670 p_ctscs
R 7637 1 7637 7637 0 0x4a014000 00000600c9be4cf0 sac
R 7695 7637 7637 7637 0 0x4a014000 00000600c98b8cd8 ttymon
R 11035 1 11 11 0 0x4a004000 00000600cdd519b8 uce_agent.sh
R 15869 11035 11 11 0 0x4a004000 00000600b2b805e0 uce_agent.bin
Z 24884 1 24884 24884 100 0x4a004002 0000030597a799a0 oracle
Z 1449 1 1449 1449 100 0x4a004002 0000030597a28050 oracle
Z 18483 1 18483 18483 100 0x4a004002 0000030597a7a638 oracle
Z 5461 1 5461 5461 100 0x4a004002 0000030597a7d998 oracle
Z 28198 1 28198 28198 100 0x4a004002 0000030597a7c068 oracle
Z 21932 1 21932 21932 100 0x4a004002 0000030597a7cd00 oracle
Z 14770 1 14770 14770 100 0x4a004002 0000030597a37368 oracle
Z 8999 1 8999 8999 100 0x4a004002 0000030597aad938 oracle
[…]
Z 13641 1 13641 13641 100 0x4a004002 0000030597aa3280 oracle
Z 12707 1 12707 12707 100 0x4a004002 0000030597aa4018 oracle
>> More [<space>, <cr>, q, n, c, a] ?

A première vue Il semble y avoir beaucoup de processus « oracle ». Piste intéressante, j’investigue.

> ::ps !grep -c oracle
29684

Confirmation qu’il s’agit bien du contributeur « oracle ». J’essaye dans savoir un peu plus.

> ::ptree
00000000018b09c0 sched
00000600e4766018 zpool-oradg00
00000600b4821960 zpool-spool
00000600b4823290 zpool-dump
00000600b21b6ca8 zpool-asmdg00
00000600b21b9270 vmtasks
000006009bdb4008 fsflush
000006009bdb4ca0 pageout
000006009bdb5938 init
0000060146e6c0d0 p_ctscd
0000060153fa8670 p_ctscs
00000600c9be4cf0 sac
00000600c98b8cd8 ttymon
00000600cdd519b8 uce_agent.sh
00000600b2b805e0 uce_agent.bin
0000030597a799a0 oracle
0000030597a28050 oracle
0000030597a7a638 oracle
0000030597a7d998 oracle
0000030597a7c068 oracle
0000030597a7cd00 oracle
0000030597a37368 oracle
0000030597aad938 oracle
[…]

Tous les processus « oracle » ont comme père le processus init. Il s’agit vraisemblablement d’un nombre important de « sessions oracle » (et non pas une fork bomb). Je vérifie.

> ::ps -ft !grep oracle
Z 24884 1 24884 24884 100 0x4a004002 0000030597a799a0 oracleBASE (LOCAL=NO)
Z 1449 1 1449 1449 100 0x4a004002 0000030597a28050 oracleBASE (LOCAL=NO)
Z 18483 1 18483 18483 100 0x4a004002 0000030597a7a638 oracleBASE (LOCAL=NO)
Z 5461 1 5461 5461 100 0x4a004002 0000030597a7d998 oracleBASE (LOCAL=NO)
Z 28198 1 28198 28198 100 0x4a004002 0000030597a7c068 oracleBASE (LOCAL=NO)
Z 21932 1 21932 21932 100 0x4a004002 0000030597a7cd00 oracleBASE (LOCAL=NO)
Z 14770 1 14770 14770 100 0x4a004002 0000030597a37368 oracleBASE (LOCAL=NO)
Z 8999 1 8999 8999 100 0x4a004002 0000030597aad938 oracleBASE (LOCAL=NO)
Z 2874 1 2874 2874 100 0x4a004002 0000030597a7e630 oracleBASE (LOCAL=NO)
Z 29899 1 29899 29899 100 0x4a004002 0000030597a88050 oracleBASE (LOCAL=NO)
Z 26317 1 26317 26317 100 0x4a004002 0000030597a7f2c8 oracleBASE (LOCAL=NO)
Z 23244 1 23244 23244 100 0x4a004002 0000030597a80cf8 oracleBASE (LOCAL=NO)
Z 20412 1 20412 20412 100 0x4a004002 0000030597a81990 oracleBASE (LOCAL=NO)
Z 16689 1 16689 16689 100 0x4a004002 0000030597a82628 oracleBASE (LOCAL=NO)
[…]

Bingo ! J’ai un coupable… Un petit tour chez les DBA Oracle pour leur expliquer que l’incident survenu sur le serveur (indisponibilité) provient de chez eux.

<troll><mode Adrien> Encore les DBA, les nuls !! Un bon DBA est un DBA … </mode Adrien></troll>

J’ai dit quoi déjà : les apparences sont quelques fois trompeuses…

<troll> Adrien, calme me toi et lis la suite </troll>

En regardant d’un peu plus près le retour des commandes « ps », un premier élément me choque.

> ::ps -ft
[…]
Z 24884 1 24884 24884 100 0x4a004002 0000030597a799a0 oracleBASE (LOCAL=NO)
Z 1449 1 1449 1449 100 0x4a004002 0000030597a28050 oracleBASE (LOCAL=NO)
Z 18483 1 18483 18483 100 0x4a004002 0000030597a7a638 oracleBASE (LOCAL=NO)
Z 5461 1 5461 5461 100 0x4a004002 0000030597a7d998 oracleBASE (LOCAL=NO)
[…]

A première vue il s’agit de processus « zombie ». Strange… Combien de processus zombie pour cette base ? Existe-t-il d’autres processus zombie ?

> ::ps -ft !grep oracleBASE | grep -c ^Z
28773

> ::ps -ft !grep ^Z | grep -cv oracleBASE
469

Attention un processus zombie consomme une entrée dans la table des processus.

On a related note, the signal flow explains why zombie processes cannot be killed (any horror movie fan knows you can’t kill a zombie). A process must be executing in order to take delivery of a signal. A zombie process is, by definition, a process that has terminated. It exists only as a process table entry, with all of its execution state having been freed by the kernel (see preap(1) for cleaning up zombie processes).

En détaillant un peu les autres processus zombie un indice me choque rapidement.

> ::ps –ft !grep ^Z | grep –v BASE
Z 1 0 0 0 0 0x4a004000 000006009bdb5938 /sbin/init
Z 29265 1 29265 29265 100 0x4a004002 000003059798f2f8 oracle+ASM (LOCAL=NO)
Z 17389 1 17389 17389 100 0x4a004002 000003059791c088 oracleXXX (LOCAL=NO)
Z 10068 1 10068 10068 100 0x4a004002 00000305979172f8 oracleXXZ (LOCAL=NO)
Z 8308 1 8308 8308 100 0x4a004002 0000030597924d10 oracleXYZ (LOCAL=NO)
Z 6559 1 6559 6559 100 0x4a004002 0000030597930060 oracleZWX (LOCAL=NO)
Z 1229 1 1229 1229 100 0x4a004002 00000305978e8100 oracleZSD (LOCAL=NO)
Z 16366 1 16366 16366 100 0x4a004002 00000305977c0060 oracleWWW (LOCAL=NO)
Z 2621 1 2621 2621 100 0x4a004002 0000030597713340 oracleQQQ (LOCAL=NO)
Z 25811 1 25519 25519 100 0x4a004002 0000030597640d28 who am i
[…]

Le process « init » est dans l’état « zombie »… C’est assez surprenant !? Normalement un processus zombie est un processus terminé en attente d’un signal wait(2).

Regardless of which event causes the process to terminate, the kernel exit function is ultimately executed, freeing whatever resources have been allocated to the process, such as the address space mappings, open files, etc., and setting the process state to SZOMB, or the zombie state. A zombie process is one that has exited and that requires the parent process to issue a wait(2) system call to gather the exit status. The only kernel resource that a process in the zombie state is holding is the process table slot. Successful execution of a wait(2) call frees the process table slot. Orphaned processes are inherited by the init process solely for this purpose.

Mais s’agissant du processus init qui va lui envoyer le signal wait(2) ?

L’état du processus « init » semble inquiétant mais pour le moment, il n’existe pas encore de relation entre l’incident de fork et l’état du processus « init ». Y’a-t-il une information dans le buffer de messages concernant le process init ?

> ::msgbuf !grep init
NOTICE: core_log: init[1] core dumped: /var/core/core_myserver_init_0_0_1358854223_1
WARNING: init(1M) core dumped on signal 11: restarting automatically
WARNING: exec(/sbin/init) failed with errno 48.
WARNING: failed to restart init(1M) (err=48): system reboot required

Le processus init a eu un petit problème (signal SIGSEGV - Segmentation Fault) et n’a pas été réactivé correctement (exec failed – errno 48). Le problème du buffer de message c’est qu’il n’y a pas de timestamp. Du coup difficile de dire si il y a un rapport ou non avec mon incident « fork ».

Un petit passage par la log système est nécessaire.

Jan 22 12:30:24 myserver genunix: [ID 603404 kern.notice] NOTICE: core_log: init[1] core dumped: /var/core/core_myserver_init_0_0_1358854223_1
Jan 22 12:30:24 myserver genunix: [ID 894729 kern.warning] WARNING: init(1M) core dumped on signal 11: restarting automatically
Jan 22 12:30:24 myserver genunix: [ID 923222 kern.warning] WARNING: exec(/sbin/init) failed with errno 48.
Jan 22 12:30:24 myserver genunix: [ID 404865 kern.warning] WARNING: failed to restart init(1M) (err=48): system reboot required

L’incident du « fork » se situe environ 35 minutes après l’incident du processus init… Quelle est la date de création de ces processus zombie ? Proviennent -ils d’avant l’incident du processus init ou pas ?

J’ai écrit un petit script pour obtenir le timestamp de création des processus (c’est pas très élégant mais ça fonctionne).

# cat /tmp/time_process_zombie
echo "::ps !grep ^Z" | mdb -k 0 | awk '{print $8}' > ps$$

while read proc
do
echo $proc | awk '{print $1}'
echo $proc | awk '{print $1,"::print proc_t p_user.u_start.tv_sec"}' | mdb unix.0 vmcore.0
done < ps$$

# cd /var/crash/myserver
# sh /tmp/bruno > liste_zombie

# cat /tmp/time_process_run
echo "::ps !grep ^R" | mdb -k 0 | awk '{print $8}' > ps$$

while read proc
do
echo $proc | awk '{print $1}'
echo $proc | awk '{print $1,"::print proc_t p_user.u_start.tv_sec"}' | mdb unix.0 vmcore.0
done < ps$$

# cd /var/crash/myserver
# sh /tmp/time_process_run > liste_run

Quelques observations après l’analyse des résultats :

Seulement 3 processus créés après l’incident du processus « init » (bien entendu ces processus n’ont pas « init » comme père et celui-ci (leur père) n’est pas dans l’état zombie).
Plus de 29300 processus zombie ont été créé à partir du 22 janvier 12:30:00.
En date du 22 janvier, le premier processus zombie a démarré vers « 2013 Jan 22 12:05:33 ».

> 00000600dd4b99c8::ps -ft
S PID PPID PGID SID UID FLAGS ADDR NAME
Z 11891 1 11891 11891 0 0x42000002 00000600dd4b99c8 /usr/lib/rcm/rcm_daemon

Il s’agit du deamon rcm_deamon. C’est quoi ce truc ? RCM « Reconfiguration Coordination Manager » est un framework qui manage la suppression automatique de composants du système.

The Reconfiguration Coordination Manager (RCM) is the framework that manages the dynamic removal of system components. By using RCM, you can register and release system resources in an orderly manner. You can use the new RCM script feature to write your own scripts to shut down your applications, or to cleanly release the devices from your applications during dynamic reconfiguration. The RCM framework launches a script automatically in response to a reconfiguration request, if the request impacts the resources that are registered by the script.

Une modification récente sur le système ? Mais oui… évidement maintenant qu’on en parle : il y a eu effectivement un changement de disque SCSI sur le châssis vers 12h00. Je vérifie rapidement l’heure de l’opération.

Jan 22 12:02:08 myserver scsi: [ID 107833 kern.warning] WARNING: /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:02:08 myserver Disconnected command timeout for Target 1
Jan 22 12:02:08 myserver scsi: [ID 243001 kern.info] /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:02:08 myserver mpt_check_scsi_io: IOCStatus=0x48 IOCLogInfo=0x31140000
Jan 22 12:03:18 myserver scsi: [ID 107833 kern.warning] WARNING: /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:03:18 myserver Disconnected command timeout for Target 1
Jan 22 12:03:19 myserver scsi: [ID 243001 kern.info] /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:03:19 myserver mpt_check_scsi_io: IOCStatus=0x48 IOCLogInfo=0x31140000
Jan 22 12:04:29 myserver scsi: [ID 107833 kern.warning] WARNING: /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:04:29 myserver Disconnected command timeout for Target 1
Jan 22 12:04:29 myserver scsi: [ID 243001 kern.info] /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:04:29 myserver mpt_check_scsi_io: IOCStatus=0x48 IOCLogInfo=0x31140000
Jan 22 12:05:39 myserver scsi: [ID 107833 kern.warning] WARNING: /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:05:39 myserver Disconnected command timeout for Target 1
Jan 22 12:05:40 myserver scsi: [ID 243001 kern.info] /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:05:40 myserver mpt_check_scsi_io: IOCStatus=0x48 IOCLogInfo=0x31140000
Jan 22 12:06:42 myserver scsi: [ID 107833 kern.warning] WARNING: /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:06:42 myserver wwn for target has changed
Jan 22 12:06:50 myserver scsi: [ID 107833 kern.warning] WARNING: /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:06:50 myserver Disconnected command timeout for Target 1
Jan 22 12:06:50 myserver scsi: [ID 107833 kern.notice] /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:06:50 myserver mpt_flush_target discovered non-NULL cmd in slot 484, tasktype 0x3
Jan 22 12:06:50 myserver scsi: [ID 365881 kern.info] /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:06:50 myserver Cmd (0x3005fa08e00) dump for Target 1 Lun 0:
Jan 22 12:06:50 myserver scsi: [ID 365881 kern.info] /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:06:50 myserver cdb=[ 0x25 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ]
Jan 22 12:06:50 myserver scsi: [ID 365881 kern.info] /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:06:50 myserver pkt_flags=0x1c000 pkt_statistics=0x0 pkt_state=0x0
Jan 22 12:06:50 myserver scsi: [ID 365881 kern.info] /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0):
Jan 22 12:06:50 myserver pkt_scbp=0x0 cmd_flags=0x860
Jan 22 12:06:53 myserver scsi: [ID 107833 kern.warning] WARNING: /pci@0,600000/pci@0/pci@8/pci@0/scsi@1/sd@1,0 (sd0):
Jan 22 12:06:53 myserver Corrupt label; wrong magic number
[…]
Jan 22 12:09:57 myserver genunix: [ID 408114 kern.info] /pci@0,600000/pci@0/pci@8/pci@0/scsi@1 (mpt0) quiesced
[…]

Que dire de plus… Le changement physique du disque semble avoir « perturber » le système au point où le processus « init » segfault. Ce type d'incident ne se produit pas souvent du coup c'est difficile de savoir ce qui doit se produire. Dans mon cas, il semble y avoir eu création d’environ 29300 processus dans un statut bizarre (zombie).

Je remercie Yahya pour m’avoir challengé sur cet incident. Sans lui, je serais passé à côté de l'état zombie d'init et jamais je n'aurais penser à vérifier les dates de création des processus. Les apparences sont quelques fois trompeuses… n'oubliez pas !?

P.S. : Yahya est DBA Oracle...

Plus
- Email
- Lien
- Imprimer

Par gloumps - Publié dans : kernel
Ecrire un commentaire - Voir les 1 commentaires

Lundi 4 février 2013 1 04 /02 /Fév /2013 21:24

Création d'un serveur AI personnalisé (archi Sparc)

Après avoir créé vos repos (méthode pas-à-pas disponible dans un précédant article), il est temps de créer votre serveur AI personnalisé. Je vais découper ce sujet en deux partie, un article sur l'architecture Sparc et un autre sur l'architecture x86. Et pourquoi donc ? J'utilise deux méthodes d'initialisations différentes, wanboot pour l'architecture Sparc et la paire pxe/dhcp pour l'architecture x86. Du coup je préfère distinguer ces deux architectures.

Pour recevoir et interpréter la procédure d'installation d'un client Sparc (via wanboot), il faut que le serveur AI soit correctement configuré (serveur web, serveur tftp et script cgi).

# pkg set-publisher –M ‘*’ –G ‘*’ -P -g http://10.xx.xx.xxx:8000 solaris
# pkg install network/tftp install/installadm
# svccfg -s system/install/server:default setprop all_services/port = 5555
# svccfg refresh system/install/server:default

# mkdir /var/ai/image-server/images/cgi-bin
# chmod 777 /var/ai/image-server/images/cgi-bin
# cp -pr /usr/lib/inet/wanboot/wanboot-cgi /var/ai/image-server/images/cgi-bin

# svccfg –s network/tftp/udp6 setprop \
netd_start/exec=”/usr/sbin/in.tftpd -s /etc/netboot”
# svcadm refresh network/tftp/udp6
# inetadm –e network/tftp/udp6

Une fois ces étapes effectuées, il faut initialiser le service d'installation pour les clients Sparc.

# installadm create-service –a sparc
Warning: Service svc:/network/dns/multicast:default is not online.
Installation services will not be advertised via multicast DNS.

Creating service from: pkg:/install-image/solaris-auto-install
OK to use subdir of /export/auto_install to store image? [y/N]: y

DOWNLOAD PKGS FILES XFER (MB) SPEED
Completed 1/1 45/45 237.8/237.8 11.5M/s

PHASE ITEMS
Installing new actions 187/187
Updating package state database Done
Updating image state Done
Creating fast lookup database Done
Reading search index Done
Updating search index 1/1

Creating sparc service: solaris11_1-sparc

Image path: /export/auto_install/solaris11_1-sparc

Service discovery fallback mechanism set up
Creating SPARC configuration file
Refreshing install services
Warning: mDNS registry of service solaris11_1-sparc could not be verified.

Creating default-sparc alias

Service discovery fallback mechanism set up
Creating SPARC configuration file
No local DHCP configuration found. This service is the default
alias for all SPARC clients. If not already in place, the following should
be added to the DHCP configuration:
Boot file: http://10.xx.xx.xxx:5555/cgi-bin/wanboot-cgi

Refreshing install services
Warning: mDNS registry of service default-sparc could not be verified.

Le service pour les clients Sparc est maintenant disponible.

# installadm list -m

Service/Manifest Name Status Criteria
--------------------- ------ --------

default-sparc
orig_default Default None

solaris11_1-sparc
orig_default Default None

Quelques personnalisations sont nécessaires (A vous de voir ce que vous souhaitez faire). Moi je personnalise de la manière suivante. Attention, dans le reste de la procédure, on utilise cette arborescence.

Le répertoire ref contient le profile de référence pour tous les clients
Le répertoire manifests contient les manifests (par mise à jour de Solaris 11)
Le répertoire clients contient les profiles personnalisés de chaque client

# cd /export/auto_install
# mkdir clients manifests ref

On crée un manifest spécifique en utilisant les commandes suivantes.

# installadm export --service solaris11_1-sparc \
--manifest orig_default \
--output /export/auto_install/manifests/sol11.1-sparc-001
# vi /export/auto_install/manifests/sol11.1-sparc-001
# installadm create-manifest \
-f /export/auto_install/manifests/sol11.1-sparc-001 \
-n solaris11_1-sparc -m sol11.1-sparc-001 -d

En cas d'autre modification sur ce manifest, on utilise les commandes suivantes.

# vi /export/auto_install/manifests/sol11.1-sparc-001
# installadm update-manifest \
-f /export/auto_install/manifests/sol11.1-sparc-001 \
-n solaris11_1-sparc -m sol11.1-sparc-001

Pour éviter de garder le service et le manifest par défaut, on nettoie un peu la configuration.

# installadm delete-service default-sparc
# installadm delete-manifest -n solaris11_1-sparc -m orig_default

On passe maintenant à la création du profile pour un client donné.

# sysconfig create-profile -o /export/auto_install/ref/profile.xml
# cd /export/auto_install/ref
# cp profile.xml ../clients/sparc-01.xml
# vi /export/auto_install/clients/sparc-01.xml

# installadm create-profile \
-f /export/auto_install/clients/sparc-01.xml \
-n solaris11_1-sparc \
-p sparc-01 -c mac="00:1x:xx:xx:xx:f2"

Reste la création du client.

# installadm create-client -e 001xxxxxxxf2 -n solaris11_1-sparc
Warning: Service svc:/network/dns/multicast:default is not online.
Installation services will not be advertised via multicast DNS.

La configuration du serveur AI est terminé et un client a été généré par rapport à un manifest et un profile spécifique.

# installadm list -c -p -m

Service Name Client Address Arch Image Path
------------ -------------- ---- ----------
solaris11_1-sparc 00:1x:xx:xx:xx:F2 sparc /export/auto_install/solaris11_1-sparc

Service/Manifest Name Status Criteria
--------------------- ------ --------

solaris11_1-sparc
sol11.1-sparc-001 Default None

Service/Profile Name Criteria
-------------------- --------

solaris11_1-sparc
sparc-01 mac = 00:1x:xx:xx:xx:F2

Depuis l'OBP du client Sparc, on configure les paramètres du wanboot et on lance l'installation.

{0} ok setenv network-boot-arguments host-ip=10.xx.xx.xxx,router-ip=10.xx.xx.1,
subnet-mask=255.xxx.xxx.xxx,file=http://10.xx.xx.xxx:5555/cgi-bin/wanboot-cgi

{0} ok boot net - install

Boot device: /pci@0,600000/pci@0/pci@8/pci@0/network@2 File and args: - install
1000 Mbps full duplex Link up
<time unavailable> wanboot info: WAN boot messages->console
<time unavailable> wanboot info: configuring /pci@0,600000/pci@0/pci@8/pci@0/network@2

1000 Mbps full duplex Link up
<time unavailable> wanboot progress: wanbootfs: Read 368 of 368 kB (100%)
<time unavailable> wanboot info: wanbootfs: Download complete
Mon Dec 17 15:49:54 wanboot progress: miniroot: Read 243471 of 243471 kB (100%)
Mon Dec 17 15:49:54 wanboot info: miniroot: Download complete

SunOS Release 5.11 Version 11.1 64-bit
Copyright (c) 1983, 2012, Oracle and/or its affiliates. All rights reserved.
Remounting root read/write
Probing for device nodes ...
Preparing network image for use

Downloading solaris.zlib
--2012-12-17 16:21:37-- http://10.xx.xx.xxx:5555/export/auto_install/solaris11_1-sparc//solaris.zlib
Connecting to 10.xx.xx.xxx:5555... connected.
HTTP request sent, awaiting response... 200 OK
Length: 133076480 (127M) [text/plain]
Saving to: `/tmp/solaris.zlib'

100%[======================================>] 133,076,480 49.6M/s in 2.6s

2012-12-17 16:21:39 (49.6 MB/s) - `/tmp/solaris.zlib' saved [133076480/133076480]

Downloading solarismisc.zlib
--2012-12-17 16:21:39-- http://10.xx.xx.xxx:5555/export/auto_install/solaris11_1-sparc//solarismisc.zlib
Connecting to 10.xx.xx.xxx:5555... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11808768 (11M) [text/plain]
Saving to: `/tmp/solarismisc.zlib'

100%[======================================>] 11,808,768 63.0M/s in 0.2s

2012-12-17 16:21:40 (63.0 MB/s) - `/tmp/solarismisc.zlib' saved [11808768/11808768]

Downloading .image_info
--2012-12-17 16:21:40-- http://10.xx.xx.xxx:5555/export/auto_install/solaris11_1-sparc//.image_info
Connecting to 10.xx.xx.xxx:5555... connected.
HTTP request sent, awaiting response... 200 OK
Length: 81 [text/plain]
Saving to: `/tmp/.image_info'

100%[======================================>] 81 --.-K/s in 0s

2012-12-17 16:21:40 (7.02 MB/s) - `/tmp/.image_info' saved [81/81]

Done mounting image
Configuring devices.
Hostname: solaris
Service discovery phase initiated
Service name to look up: solaris11_1-sparc
Service discovery over multicast DNS failed
Service solaris11_1-sparc located at 10.xx.xx.xxx:5555 will be used
Service discovery finished successfully
Process of obtaining install manifest initiated
Using the install manifest obtained via service discovery

solaris console login:

Automated Installation started
The progress of the Automated Installation will be output to the console
Detailed logging is in the logfile at /system/volatile/install_log

Press RETURN to get a login prompt at any time.

16:22:08 Using XML Manifest: /system/volatile/ai.xml
16:22:08 Using profile specification: /system/volatile/profile
16:22:08 Using service list file: /var/run/service_list
16:22:08 Starting installation.
16:22:08 0% Preparing for Installation
16:22:08 100% manifest-parser completed.
16:22:09 0% Preparing for Installation
16:22:09 1% Preparing for Installation
16:22:09 2% Preparing for Installation
16:22:09 3% Preparing for Installation
16:22:09 4% Preparing for Installation
16:22:24 7% target-discovery completed.
16:22:24 Selected Disk(s) : c2t0d0
16:22:24 13% target-selection completed.
16:22:24 17% ai-configuration completed.
16:22:24 19% var-share-dataset completed.
16:22:41 21% target-instantiation completed.
16:22:41 21% Beginning IPS transfer
16:22:41 Creating IPS image
16:22:45 Startup: Retrieving catalog 'solaris' ... Done
16:22:48 Startup: Caching catalogs ... Done
16:22:48 Startup: Refreshing catalog 'site' ... Done
16:22:48 Startup: Refreshing catalog 'solaris' ... Done
16:22:51 Startup: Caching catalogs ... Done
16:22:51 Installing packages from:
16:22:51 solaris
16:22:51 origin: http://10.xx.xx.xxx:8000/
16:22:51 site
16:22:51 origin: http://10.xx.xx.xxx:8001/
16:22:51 Startup: Refreshing catalog 'site' ... Done
16:22:52 Startup: Refreshing catalog 'solaris' ... Done
16:22:56 Planning: Solver setup ... Done
16:22:56 Planning: Running solver ... Done
16:22:56 Planning: Finding local manifests ... Done
16:22:56 Planning: Fetching manifests: 0/365 0% complete
16:23:03 Planning: Fetching manifests: 100/365 27% complete
16:23:08 Planning: Fetching manifests: 253/365 69% complete
16:23:16 Planning: Fetching manifests: 365/365 100% complete
16:23:25 Planning: Package planning ... Done
16:23:26 Planning: Merging actions ... Done
16:23:29 Planning: Checking for conflicting actions ... Done
16:23:31 Planning: Consolidating action changes ... Done
16:23:34 Planning: Evaluating mediators ... Done
16:23:37 Planning: Planning completed in 45.22 seconds
16:23:37 Please review the licenses for the following packages post-install:
16:23:37 runtime/java/jre-7 (automatically accepted)
16:23:37 consolidation/osnet/osnet-incorporation (automatically accepted,
16:23:37 not displayed)
16:23:37 Package licenses may be viewed using the command:
16:23:37 pkg info --license <pkg_fmri>
16:23:38 Download: 0/51156 items 0.0/831.8MB 0% complete
16:23:43 Download: 837/51156 items 5.4/831.8MB 0% complete (1.1M/s)

[…]

16:29:37 Download: 50159/51156 items 828.7/831.8MB 99% complete (714k/s)
16:29:42 Download: 50971/51156 items 831.1/831.8MB 99% complete (619k/s)
16:29:43 Download: Completed 831.78 MB in 365.45 seconds (2.3M/s)
16:29:55 Actions: 1/73904 actions (Installing new actions)
16:30:00 Actions: 15949/73904 actions (Installing new actions

[…]

16:34:51 Actions: 72496/73904 actions (Installing new actions)
16:34:56 Actions: 72687/73904 actions (Installing new actions)
16:35:01 Actions: Completed 73904 actions in 305.77 seconds.
16:35:02 Finalize: Updating package state database ... Done
16:35:04 Finalize: Updating image state ... Done
16:35:16 Finalize: Creating fast lookup database ... Done
16:35:24 Version mismatch:
16:35:24 Installer build version: pkg://solaris/entire@0.5.11,5.11-0.175.1.0.0.24.2:20120919T190135Z
16:35:24 Target build version: pkg://solaris/entire@0.5.11,5.11-0.175.1.1.0.4.0:20121106T001344Z
16:35:24 23% generated-transfer-1181-1 completed.
16:35:25 25% initialize-smf completed.
16:35:25 Boot loader type SPARC ZFS Boot Block does not support the ...
16:35:25 Installing boot loader to devices: ['/dev/rdsk/c2t0d0s0']
16:35:26 Setting boot devices in firmware
16:35:26 Setting openprom boot-device
16:35:27 35% boot-configuration completed.
16:35:27 37% update-dump-adm completed.
16:35:27 40% setup-swap completed.
16:35:27 42% device-config completed.
16:35:28 44% apply-sysconfig completed.
16:35:29 46% transfer-zpool-cache completed.
16:35:38 87% boot-archive completed.
16:35:38 89% transfer-ai-files completed.
16:35:39 99% create-snapshot completed.
16:35:39 Automated Installation succeeded.
16:35:39 System will be rebooted now

Automated Installation finished successfully
Auto reboot enabled. The system will be rebooted now
Log files will be available in /var/log/install/ after reboot
Dec 17 16:35:43 solaris reboot: initiated by root
Dec 17 16:35:50 solaris syslogd: going down on signal 15
syncing file systems... done
rebooting...

La configuration d'un serveur AI et la personnalisation d'un client (manifest et profile) sont des étapes assez simple à mettre en place. Il est grand temps maintenant, pour vous, de mettre en place votre architecture d'installation pour Solaris 11.

Plus
- Email
- Lien
- Imprimer

Par gloumps - Publié dans : administration
Ecrire un commentaire - Voir les 0 commentaires

Vendredi 1 février 2013 5 01 /02 /Fév /2013 23:25

Consommation CPU & Gestion mémoire (2ème partie)

Cela fait déjà un petit moment que j'ai écrit la 1er partie de cet article et j'imagine que vous aviez hâte dans connaître le dénouement ?

Pour rappel, la forte consommation CPU (notamment le temps system) provenait de l'agent Grid d'Oracle. Suite à la modification dans le kernel du mode d'allocation des pages (pg_contig_disable), la charge CPU semblait se répartir plus équitablement entre le temps system et le temps user. Mais... quelque chose me choquait encore...

# vmstat 5
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr m1 m1 s0 s1 in sy cs us sy id
10 0 0 10703368 22253264 686 5492 144 0 0 0 0 25 4 4 4 14772 115284 20499 46 28 26
6 0 0 25164544 7403960 1041 8609 0 0 0 0 0 1 0 0 0 13946 131868 24255 45 52 3
5 0 0 25236360 7412640 892 7452 0 0 0 0 0 1 0 0 0 17576 142221 28069 47 44 9
0 0 0 25265688 7406912 960 8391 0 0 0 0 0 1 0 0 0 17918 151723 29192 46 45 8
0 0 0 25273088 7403816 1053 9120 0 0 0 0 0 1 0 6 6 17035 189702 29475 47 45 8
1 0 0 25212800 7387888 861 7344 0 0 0 0 0 1 0 0 0 17021 148306 27156 48 46 6
1 0 0 25269080 7405256 996 8419 0 0 0 0 0 1 0 0 0 17066 143782 27059 45 44 12

La répartition du temps system et du temps user est bien égale. Ce qui me semble surprenant c'est d'avoir un temps system aussi important pour ce type d'application : exécution de bases Oracle. Du temps system pour des bases de données, je veux comprendre pourquoi.

# dtrace -n 'profile-997hz /arg0/ { @[func(arg0)] = count(); }'
dtrace: description 'profile-997hz ' matched 1 probe
^C
[…]
unix`page_lookup_create 463
unix`bzero 509
unix`utl0 510
unix`mutex_exit 693
genunix`avl_walk 843
FJSV,SPARC64-VI`cpu_halt_cpu 1243
unix`page_exists 2782
unix`mutex_delay_default 2887
unix`page_trylock 3086
FJSV,SPARC64-VI`copyout_more 3455
unix`mutex_enter 5212

Encore des mutex !! Toujours des mutex !? Si vous avez bien suivie la 1er partie de cette analyse, après l'agent Grid, le deuxième contributeur des muxtex était Oracle. Mais vérifions tout de même.

# dtrace -n 'lockstat::mutex_enter: { @[execname] = count(); }'
dtrace: description 'lockstat::mutex_enter: ' matched 3 probes
^C
[…]
emdctl 15109
init 19896
dtrace 21512
sldrm_hist 61435
zpool-zone039 85352
sched 236548
sldrm_coll 508763
perl 697386
fsflush 1168071
emagent 1590809
tnslsnr 2150743
oracle 10154578

Regardons dans le détails la ressource utilisée pour ce type de mutex.

# dtrace -n 'lockstat::mutex_enter: /execname == "oracle"/ \
{ @[stack()] = count(); } tick-60s { trunc(@,5); exit(0); }'
dtrace: description 'lockstat::mutex_enter: ' matched 4 probes
CPU ID FUNCTION:NAME
3 65327 :tick-60s

[…]

unix`page_trylock+0x38
unix`page_trylock_cons+0xc
unix`page_get_mnode_freelist+0x19c
unix`page_get_freelist+0x430
unix`page_create_va+0x258
genunix`swap_getapage+0x168
genunix`swap_getpage+0x4c
genunix`fop_getpage+0x44
genunix`anon_private+0x140
genunix`segvn_faultpage+0x808
genunix`segvn_fault+0xbf0
genunix`as_fault+0x4c8
unix`pagefault+0xac
unix`trap+0xd50
unix`utl0+0x4c
3818149

unix`page_trylock+0x38
unix`page_trylock_cons+0xc
unix`page_get_mnode_freelist+0x19c
unix`page_get_freelist+0x430
unix`page_create_va+0x258
genunix`swap_getapage+0x168
genunix`swap_getpage+0x4c
genunix`fop_getpage+0x44
genunix`anon_zero+0x88
genunix`segvn_faultpage+0x1e0
genunix`segvn_fault+0xbf0
genunix`as_fault+0x4c8
unix`pagefault+0xac
unix`trap+0xd50
unix`utl0+0x4c
26458018

Ce résultat est vraiment intéressant : mon temps system (induit par des mutex) est consécutif à des pagefault. Oracle effectue des opérations ZFOD (anon_zero) pour allouer de nouvelles pages type anonymous memory (l'info en plus : le backing store des pages anonymous memory est le swap space - explications des opérations types swap_getpage).

Le serveur dispose de plusieurs zones qui exécutent plusieurs bases de données Oracle. Le problème est'il localisé à une zone, une base ? Ou bien une problème générale sur le serveur ? Vérifions cela.

# dtrace -n '::anon_zero:entry /execname == "oracle"/ \
{ @[zonename] = count(); }'
dtrace: description '::anon_zero:entry ' matched 1 probe
^C

global 1004
zone013 2775
zone015 3266
zone034 7206
zone043 16857
zone039 319582

# dtrace -n '::anon_zero:entry /zonename == "zone039" \
&& execname == "oracle"/ { @[pid] = count(); }'
dtrace: description '::anon_zero:entry ' matched 1 probe
^C
[…]

4387 599
3903 815
29484 930
17591 991
13001 3763
18422 6550

Deux PID semblent sortir du lot lors de ma prise de mesures.

# ptree 18422
18422 oracleXXXX1 (LOCAL=NO)

# ptree 13001
13001 oracleXXXX1 (LOCAL=NO)

Pour résumé, mes mutex proviennent d'allocation ZFOD effectuée par des sessions Oracle à une base spécifique. On se rapproche de la conclusion. Mais avant essayons dans savoir plus en affichant ce qui se passe en temps user pour un des process trouvé.

# dtrace -n '::anon_zero:entry /pid == 18422/ \
{ @[ustack()] = count(); } tick-30s { trunc(@,5); exit(0); }'
dtrace: description '::anon_zero:entry ' matched 2 probes
CPU ID FUNCTION:NAME
11 65327 :tick-30s

libc_psr.so.1`memset+0x140
oracle`klmalf+0x3c
oracle`kllcqas+0xb8
oracle`kcblasm+0x48
oracle`kxhfNewBuffer+0x270
oracle`qerhjSplitBuild+0x250
oracle`qerixtFetch+0x558
oracle`rwsfcd+0x6c
oracle`qerhjFetch+0x530
oracle`qervwFetch+0x94
oracle`rwsfcd+0x6c
oracle`qerhjFetch+0x530
oracle`qerjotFetch+0x1f0
oracle`qerjotFetch+0x1f0
oracle`qerjotFetch+0x1f0
oracle`opifch2+0x28f4
oracle`opiall0+0x884
oracle`opial7+0x390
oracle`opiodr+0x590
oracle`ttcpip+0x420
1200

oracle`qerhjBuildHashTable+0x784
oracle`qerhjInnerProbeHashTable+0x250
oracle`qerixtFetch+0x558
oracle`rwsfcd+0x6c
oracle`qerhjFetch+0x1c8
oracle`qervwFetch+0x94
oracle`rwsfcd+0x6c
oracle`qerhjFetch+0x530
oracle`qerjotFetch+0x1f0
oracle`qerjotFetch+0x1f0
oracle`qerjotFetch+0x1f0
oracle`opifch2+0x28f4
oracle`opiall0+0x884
oracle`opial7+0x390
oracle`opiodr+0x590
oracle`ttcpip+0x420
oracle`opitsk+0x5e8
oracle`opiino+0x3e8
oracle`opiodr+0x590
oracle`opidrv+0x448
1405

libc_psr.so.1`memset+0x140
oracle`klmalf+0x3c
oracle`kllcqas+0xb8
oracle`kcblasm+0x48
oracle`kxhfNewBuffer+0x270
oracle`qerhjGetNewBuffer+0x24
oracle`ksxb1bqb+0xa0
oracle`kxhrPack+0x564
oracle`qerhjSplitBuild+0x164
oracle`qerixtFetch+0x558
oracle`rwsfcd+0x6c
oracle`qerhjFetch+0x530
oracle`qervwFetch+0x94
oracle`rwsfcd+0x6c
oracle`qerhjFetch+0x530
oracle`qerjotFetch+0x1f0
oracle`qerjotFetch+0x1f0
oracle`qerjotFetch+0x1f0
oracle`opifch2+0x28f4
oracle`opiall0+0x884
2400

libc_psr.so.1`memset+0x140
oracle`qerhjBuildHashTable+0x228
oracle`qerhjInnerProbeHashTable+0x250
oracle`qerixtFetch+0x558
oracle`rwsfcd+0x6c
oracle`qerhjFetch+0x1c8
oracle`qervwFetch+0x94
oracle`rwsfcd+0x6c
oracle`qerhjFetch+0x530
oracle`qerjotFetch+0x1f0
oracle`qerjotFetch+0x1f0
oracle`qerjotFetch+0x1f0
oracle`opifch2+0x28f4
oracle`opiall0+0x884
oracle`opial7+0x390
oracle`opiodr+0x590
oracle`ttcpip+0x420
oracle`opitsk+0x5e8
oracle`opiino+0x3e8
oracle`opiodr+0x590
5110

libc_psr.so.1`memset+0x140
oracle`klmalf+0x3c
oracle`kllcqas+0xb8
oracle`kcblasm+0x48
oracle`kxhfNewBuffer+0x270
oracle`qerhjGetNewBuffer+0x24
oracle`ksxb1bqb+0xa0
oracle`kxhrPack+0x534
oracle`qerhjSplitBuild+0x164
oracle`qerixtFetch+0x558
oracle`rwsfcd+0x6c
oracle`qerhjFetch+0x530
oracle`qervwFetch+0x94
oracle`rwsfcd+0x6c
oracle`qerhjFetch+0x530
oracle`qerjotFetch+0x1f0
oracle`qerjotFetch+0x1f0
oracle`qerjotFetch+0x1f0
oracle`opifch2+0x28f4
oracle`opiall0+0x884
6000

Je suis loin d’être spécialiste Oracle DB, mais d’après les ustack il s’agit d’une "hash join" (kxhf*). La zone mémoire utilisée pour ce genre d’opérations est normalement la zone SQL Work Areas (sous-ensemble de la PGA). Deux pistes sont donc à vérifier : n’y a-t-il pas un problème avec la requête SQL (pb de jointure ?) ou bien n’y a-t-il pas un problème de dimensionnement de la PGA ?

Un petit passage par l’équipe DBA Oracle s’impose…

Epilogue : en recherchant dans l’historique du monitoring, le problème de l’agent Grid provenait aussi de cette base. Bizarre non !? Comme l'a souligné Eric G. dans son commentaire sur la 1er partie, si un élément de surveillance (ici l'agent Grid) pose problème, il doit y avoir un autre problème. Pour cette fois c'est exact...

Plus
- Email
- Lien
- Imprimer

Par gloumps - Publié dans : kernel
Ecrire un commentaire - Voir les 0 commentaires

Jeudi 31 janvier 2013 4 31 /01 /Jan /2013 21:28

Création pas-à-pas des repos sous Solaris 11

Ci-joint la procédure de création pas-à-pas des principales repo pour Solaris 11. Rien de plus simple... vous allez voir !

On commence par créer les différentes repos.

# zfs create –o atime=off –o mountpoint=/repo rpool/repo
# pkgrepo create /repo/solaris
# pkgrepo create /repo/site
# pkgrepo create /repo/solarisstudio
# pkgrepo create /repo/cluster

La repo site contiendra les packages IPS locaux (packages maison). Pour provisonner les autres repos, j'utilise les packages sous support (contrat de support valide). Les certificats sont disponibles à l'adresse suivante : https://pkg-register.oracle.com.

Je considére que les certificats sont disponibles dans le répertoire /tmp de mon serveur après les avoir téléchargé.

# mkdir -m 0755 -p /var/pkg/ssl
# cp -i /tmp/Ora* /var/pkg/ssl
# ls /var/pkg/ssl
Oracle_Solaris_11_Support.certificate.pem
Oracle_Solaris_11_Support.key.pem
Oracle_Solaris_Cluster_4_Support.certificate.pem
Oracle_Solaris_Cluster_4_Support.key.pem
Oracle_Solaris_Studio_Support.certificate.pem
Oracle_Solaris_Studio_Support.key.pem

Je considère aussi que mon serveur peut se connecter à internet (via un proxy web). Il suffit alors de provisionner chaque repo de la manière suivante (en exemple la repo solaris).

# export http_proxy=http://my-proxy:8080/
# export https_proxy=https://my-proxy:8080/
# export PKG_SRC=https://pkg.oracle.com/solaris/support/
# export PKG_DEST=/repo/solaris

# pkgrecv --key /var/pkg/ssl/Oracle_Solaris_11_Support.key.pem \
--cert /var/pkg/ssl/Oracle_Solaris_11_Support.certificate.pem \
-m all-versions '*'

# pkgrepo refresh -s /repo/solaris

La repo solaris est maintenant provisonnée. Il reste à effectuer cette opération pour toutes les autres repos (execption pour la repo site). Une fois ces opérations terminées, il suffit de configurer ces différentes repos pour pouvoir y accéder à distance (j'utilise le protocole http).

On configure la repo par défaut (server) qui correspond à solaris (le choix du port est arbitraire).

# svccfg -s application/pkg/server setprop pkg/inst_root=/repo/solaris
# svccfg -s application/pkg/server setprop pkg/readonly=true
# svccfg -s application/pkg/server setprop pkg/port=8000
# svcadm refresh svc:/application/pkg/server:default
# svcadm enable svc:/application/pkg/server:default

Pour les autres repos, je duplique simplement le manifest pkg-server.xml et modifie le nom du manifest avant de les importer dans la base smf.

# cd /lib/svc/manifest/application/pkg
# cp pkg-server.xml pkg-cluster.xml
# cp pkg-server.xml pkg-studio.xml
# cp pkg-server.xml pkg-site.xml

# ls -l
total 59
-r--r--r-- 1 root sys 3843 Jan 14 14:42 pkg-site.xml
-r--r--r-- 1 root sys 3855 Jan 14 17:38 pkg-cluster.xml
-r--r--r-- 1 root sys 2546 Oct 24 11:55 pkg-mdns.xml
-r--r--r-- 1 root sys 3850 Oct 24 11:55 pkg-server.xml
-r--r--r-- 1 root sys 3859 Jan 14 14:58 pkg-studio.xml
-r--r--r-- 1 root sys 4651 Oct 24 11:58 pkg-system-repository.xml
-r--r--r-- 1 root sys 2098 Oct 24 11:49 zoneproxyd.xml

# vi pkg-cluster.xml pkg-studio.xml pkg-site.xml

# scvcfg import ./pkg-cluster.xml
# scvcfg import ./pkg-studio.xml
# scvcfg import ./pkg-site.xml

Quelques modifications sont nécessaires avant d'activer ces repos.

# svccfg -s application/pkg/site setprop pkg/inst_root=/repo/site
# svccfg -s application/pkg/site setprop pkg/port=8001
# svcadm refresh svc:/application/pkg/site:default
# scvadm enable svc:/application/pkg/site:default

# svccfg -s application/pkg/studio setprop pkg/inst_root=/repo/solarisstudio
# svccfg -s application/pkg/studio setprop pkg/port=8002
# svcadm refresh svc:/application/pkg/studio:default
# scvadm enable svc:/application/pkg/studio:default

# svccfg -s application/pkg/cluster setprop pkg/inst_root=/repo/cluster
# svccfg -s application/pkg/cluster setprop pkg/port=8003
# svcadm refresh svc:/application/pkg/cluster:default
# scvadm enable svc:/application/pkg/cluster:default

Une petite mise à jour de mes publishers en local.

# pkg set-publisher -M '*' -G '*' -P -g http://10.xx.xx.100:8000/ solaris
# pkg set-publisher -M '*' -G '*' -P -g http://10.xx.xx.100:8001/ site
# pkg set-publisher -M '*' -G '*' -P -g http://10.xx.xx.100:8002/ solarisstudio
# pkg set-publisher -M '*' -G '*' -P -g http://10.xx.xx.100:8003/ ha-cluster

# pkg publisher
PUBLISHER TYPE STATUS P LOCATION
solaris origin online F http://10.xx.xx.100:8000/
site origin online F http://10.xx.xx.100:8001/
solarisstudio origin online F http://10.xx.xx.100:8002/
ha-cluster origin online F http://10.xx.xx.100:8003/

Et hop c'est terminé. Alors c'est simple non ? Pour vérifier l'accès aux différentes repos, il suffit simplement de tester l'accès au url dans un navigateur web (ou via la commande wget).

Pour aller plus loin :

Doc Oracle : Copying and Creating Oracle Solaris 11.1 Package Repositories

Plus
- Email
- Lien
- Imprimer

Par gloumps - Publié dans : administration
Ecrire un commentaire - Voir les 0 commentaires

Mercredi 30 janvier 2013 3 30 /01 /Jan /2013 22:46

grub2 : configuration de la console série

Depuis Solaris 11 update 1, le chain loader utilisé pour les plateforme x86 est GRUB2. Le fichier de configuration présent dans GRUB (menu.lst) est remplacé par un nouveau fichier nommé grub.cfg. L'édition de ce fichier est normallement déconseillé, du coup la mise à jour s'effectue via la commande bootadm.

Si comme moi, vous utilisez la redirection série (pour l'accès au déport console) sur les serveurs x86, il est nécessaire de paramétrer correctement les options de GRUB2.

Lister la configuration disponible

# bootadm list-menu
the location of the boot loader configuration files is: /rpool/boot/grub
default 0
console text
timeout 30
0 Oracle Solaris 11.1

Modifier la redirection du déport console sur le com1

# bootadm change-entry -i 0 kargs=console=ttya

Afficher la configuration actuelle du choix 0

# bootadm list-menu -i 0
the location of the boot loader configuration files is: /rpool/boot/grub
title: Oracle Solaris 11.1
kernel: /platform/i86pc/kernel/amd64/unix
kernel arguments: console=ttya
boot archive: /platform/i86pc/amd64/boot_archive
bootfs: rpool/ROOT/solaris

Lors de l'installation d'un serveur avec Solaris 11, vous avez la possibilité de vous connecter à votre serveur pendant le processus d'installation. Cette fonctionnalité est disponible par défaut pour les platefornes Sparc uniquement. Pour les palteformes x86, une modification de GRUB2 est nécassaire.

Lors de l'initialisation de votre client sur le serveur ai, utilliser simplement la syntaxe suivante

# installadm create-client -e 00xxxxxxxxxx -n solaris11_1-i386 \
-b console=ttya,livessh=enable,install_debug=enable

Rien de plus facile, non !?

Pour aller plus loin :

Doc Oracle : Booting and Shutting Down Oracle Solaris 11.1 Systems
Doc Oracle : Installing Oracle Solaris 11.1 Systems

Plus
- Email
- Lien
- Imprimer

Par gloumps - Publié dans : administration
Ecrire un commentaire - Voir les 0 commentaires

Mardi 8 janvier 2013 2 08 /01 /Jan /2013 20:54

BrandZ Solaris 10 (exemples de migration P2V et V2V)

Comment réduire efficacement les coûts d'une infrastructure de serveurs sous Solaris 10 ? En les consolidant !! Cela va de soi, la forte utilisation des zones en est un très bonne exemple. Oui mais... Pourquoi ne pas utiliser les nouvelles possibilités qui s'offrent à nous : Un serveur sous Solaris 11 et des brandZ Solaris 10.

Je vous présente deux exemples rapides de migration d'environnements Solaris 10 physique (P2V) et Solaris 10 zone (V2V) sur un serveur Solaris 11.

Quelques prérequis sont obligatoires sur le serveur source :

Patch kernel 142909-17 (SPARC) ou 142910-17 (x86 et x64)
Patch 119254-75, 119534-24 et 140914-02 (SPARC)
Patch 119255-75, 119535-24 et 140915-02 (x86/x64)

Systèmes de fichiers racine en ZFS uniquement pour la migration P2V

Exemple de Migration P2V

Les actions ci-dessous sont à réaliser sur le serveur source Solaris 10

J'utilise l'utilitaire (disponible via MOS) SUNWzonep2vchk pour valider rapidement ma migration.

# ls
SUNWzonep2vchk.zip

# unzip SUNWzonep2vchk.zip
Archive: SUNWzonep2vchk.zip
creating: SUNWzonep2vchk/
[...]

# pkgadd -d . SUNWzonep2vchk
[...]

/opt/SUNWzonep2vchk/bin/zonep2vchk
/opt/SUNWzonep2vchk/man/man1/zonep2vchk.1m

[...]
Installation of <SUNWzonep2vchk> was successful.

Quelques checks rapides pour paramétrer au mieux mon futur environnement.

# cd /opt/SUNWzonep2vchk/bin
# ./zonep2vchk -T S11

-- Executing Version: 1.0.5-11-16135

- Source System: myserver10

Solaris Version: Solaris 10 8/07 s10s_u4wos_12b SPARC
Solaris Kernel: 5.10 Generic_147440-23
Platform: sun4u SUNW,Sun-Fire-V210

- Target System:

Solaris_Version: Solaris 11
Zone Brand: solaris10 (Solaris 10 Container)
IP type: exclusive

-- Executing basic checks

- The following /etc/system tunables exist. These tunables will not
function inside a zone. The /etc/system tunable may be transfered to
the target global zone, but it will affect the entire system,
including all zones and the global zone. If there is an
alternate tunable that can be configured from within the zone,
this tunable is described:

set noexec_user_stack=1
zonep2vchk has no information on tunable

set noexec_user_stack_log=1
zonep2vchk has no information on tunable

set tod_validate_enable=0
zonep2vchk has no information on tunable

set c2audit:audit_load = 1
Replacement tunable exists on target host:
utility auditconfig(1m)

set rlim_fd_cur = 1024
Alternate tunable exists inside a non-global zone:
rctl process.max-file-descriptor

- The following boot environments will not be usable. Only the active
boot environment will be usable in the target non-global zone:

newBE

- The following ntp client service is enabled. This service updates
the system clock. Since all zones share the same system clock, this
service is disabled automatically during p2v. If it is desired
that the zone update the system clock on the target host, the
zone will need the privilege "sys_time", and the service will
need to be enabled inside the zone after p2v. See the description
of the "limitpriv" property in zonecfg(1m):

svc:/network/ntp:default

Basic checks compete, 7 issue(s) detected

-- Total issue(s) detected: 7

Pour obtenir facilement le fichier template nécessaire à la création de la brandZ Solaris 10, j'utilise encore l'utilitaire zonep2vcheck.

# ./zonep2vchk -T S11 -c
create -b
set zonepath=/zones/myserver10
set brand=solaris10
add attr
set name="zonep2vchk-info"
set type=string
set value="p2v of host myserver10"
end
set ip-type=exclusive
# Uncomment the following to retain original host hostid:
# set hostid=845b7f42
# Max procs and lwps based on max_uproc/v_proc
set max-processes=20000
set max-lwps=40000
add attr
set name=num-cpus
set type=string
set value="original system had 2 cpus"
end

# Only one of dedicated or capped cpu can be used.
# Uncomment the following to use cpu caps:
# add capped-cpu
# set ncpus=2.0
# end

# Uncomment the following to use dedicated cpu:
# add dedicated-cpu
# set ncpus=2
# end

# Uncomment the following to use memory caps.
# Values based on physical memory plus swap devices:
# add capped-memory
# set physical=4096M
# set swap=20099M
# end

# Original bge1 interface configuration:
# Statically defined 10.30.228.92 (myzone10)
# Factory assigned MAC address 0:14:4f:5b:7f:42

add anet
set linkname=bge1
set lower-link=change-me
# Uncomment the following to retain original link configuration:
# set mac-address=0:14:4f:5b:7f:42
end
exit

Pour obtenir facilement une image cohérente, je reboote en single le serveur source. J'utilise ici un serveur nfs pour héberger temporairement mon image flar.

# init 0
Creating boot_archive for /a
updating /a/platform/sun4u/boot_archive
# syncing file systems... done
Program terminated

{0} ok boot -s

Boot device: /pci@1c,600000/scsi@2/disk@1,0:a File and args: -s
SunOS Release 5.10 Version Generic_147440-23 64-bit
Copyright (c) 1983, 2012, Oracle and/or its affiliates. All rights reserved.
Hardware watchdog enabled
Booting to milestone "milestone/single-user:default".
Hostname: myserver10
Requesting System Maintenance Mode
SINGLE USER MODE

Root password for system maintenance (control-d to bypass):
single-user privilege assigned to /dev/console.
Entering System Maintenance Mode

Jan 2 18:16:22 su: 'su root' succeeded for root on /dev/console
Sun Microsystems Inc. SunOS 5.10 Generic January 2005

# mount –F nfs nfsserver:/myshare /mnt
# zfs mount -a
# flarcreate -n myserver10 -c /mnt/myserver10.flar

Full Flash
Checking integrity...
Integrity OK.
Running precreation scripts...
Precreation scripts done.
Determining the size of the archive...
The archive will be approximately 9.05GB.
Creating the archive...
Archive creation complete.
Running postcreation scripts...
Postcreation scripts done.

Running pre-exit scripts...
Pre-exit scripts done.

J'utilise plusieurs autres datasets ZFS attachés directement au dataset rpool. Du coup lors de la création du flar, ces datasets ne sont pas pris en compte. J'utilise donc des petits snapshots ZFS pour pouvoir recopier mes données sur la future brandZ Solaris 10.

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 50.7G 16.2G 33.5K /rpool
rpool/ROOT 24.4G 16.2G 23K legacy
rpool/ROOT/zfsBE 24.4G 16.2G 19.9G /
rpool/ROOT/zfsBE/var 4.54G 16.2G 4.54G /var
rpool/apps 8.05G 16.2G 8.05G /apps
rpool/dump 2.00G 16.2G 2.00G -
rpool/export 1.39G 629M 1.39G /export
rpool/swap 14.9G 16.2G 14.9G -

# zfs snapshot rpool/export@now
# zfs snapshot rpool/apps@now
# zfs send rpool/export@now > /mnt/export
# zfs send rpool/apps@now > /mnt/apps

Les actions ci-dessous sont à réaliser sur le serveur destination Solaris 11

La première étape est de créer la brandZ Solaris 10 sur le serveur Solaris 11.

# zpool create myserver10 cXtYdZ
# zfs set mountpoint=/zones/myserver10
# chmod 700 /zones/myserver10

# cat /var/tmp/myserver10
create -b
set zonepath=/zones/myserver10
set brand=solaris10
set ip-type=shared
add net
set address=192.xx.xx.xx/xx
set physical=ipmp0
end
set hostid=845b7f42
exit

Comme vous pouvez le constater, j'ai réduit consiérablement le fichier template pour la création de la zone. J'ai apporté notamment la modification suivante : ip-type=shared. En fait j'ai configuré un groupe ipmp sur mon serveur Solaris 11, il m'est alors impossible de créer des vnic via l'interface ipmp. Du coup je préfére utiliser le mode shared.

# zonecfg –z myserver10 –f /var/tmp/myserver10
# zoneadm list –cv
ID NAME STATUS PATH BRAND IP
0 global running / solaris shared
- myserver10 configured /zones/myserver10 solaris10 shared

Je lance maintenant le chargement des données dans ma brandZ Solaris 10.

# mount –F nfs nfsserver:/myshare /mnt
# zoneadm -z myserver10 install -p -a /tools/myserver10.flar

Progress being logged to /var/log/zones/zoneadm.20130103T135726Z.myserver10.install
Installing: This may take several minutes...

Postprocessing: This may take a while...
Postprocess: Updating the image to run within a zone

Result: Installation completed successfully.

Log saved in non-global zone as /zones/myzone10/root/var/log/zones/zoneadm.20130103T135726Z.myserver10.install

# zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / solaris shared
- myserver10 installed /zones/myserver10 solaris10 shared

L'installation s'est correctement déroulée. Reste encore quelques modifications à faire pour finaliser complétement la migration P2V. Il nous manque les données contenues dans les différents snapshots.

# zfs list -r myserver10
NAME USED AVAIL REFER MOUNTPOINT
myserver10 24.5G 42.0G 33K /zones/myserver10
myserver10/rpool 24.5G 42.0G 31K /rpool
myserver10/rpool/ROOT 24.5G 42.0G 31K legacy
myserver10/rpool/ROOT/zbe-0 24.5G 42.0G 19.6G /zones/myserver10/root
myserver10/rpool/ROOT/zbe-0/var 4.55G 42.0G 4.54G /zones/myserver10/root/var

# zfs receive myserver10/rpool/ROOT/zbe-0/apps < /mnt/apps
# zfs receive myserver10/rpool/ROOT/zbe-0/export < /mnt/export

# zfs list -r myserver10
NAME USED AVAIL REFER MOUNTPOINT
myserver10 33.9G 32.5G 33K /zones/myserver10
myserver10/rpool 33.9G 32.5G 31K /rpool
myserver10/rpool/ROOT 33.9G 32.5G 31K legacy
myserver10/rpool/ROOT/zbe-0 33.9G 32.5G 19.6G /zones/myserver10/root
myserver10/rpool/ROOT/zbe-0/apps 8.05G 32.5G 8.05G /apps
myserver10/rpool/ROOT/zbe-0/export 1.39G 32.5G 1.39G /export
myserver10/rpool/ROOT/zbe-0/var 4.55G 32.5G 4.54G /zones/myserver10/root/var

Et voilà notre migration P2V est terminée. N'oublier pas de modifier les quelques paramètres obtenus lors de votre check : comme par exemple désactiver le ntp, le nombre de file descriptor, etc.

# zoneadm -z myserver10 boot

Migration V2V

Les actions ci-dessous sont à réaliser sur le serveur source Solaris 10 hébergeant la zone à migrer

Il faut stopper la zone Solaris 10 et l'activer dans un mode particulier pour créer l'archive. J'utilise toujours un serveur nfs pour stocker mon archive flar.

# mount -F nfs nfsserver:/myshare /mnt

# zoneadm –z myzone10 halt
# zoneadm –z myzone10 ready
# zonecfg –z myzone10 info | grep zonepatch
zonepath: /zones/myzone10

# cd /zones/myzone10
# find root -print | cpio –oH crc -oP@ | gzip >/mnt/myzone10.cpio.gz

Je récupére les infos nécessaires à la création du template de la futur brandZ Solaris 10.

# zonecfg -z myzone10 info
zonename: myzone10
zonepath: /zones/myzone10
brand: native
autoboot: false
bootargs:
pool:
limitpriv:
scheduling-class:
ip-type: shared
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
fs:
dir: /sources
special: /datas/myzone10/source
raw not specified
type: lofs
options: []
fs:
dir: /appli
special: /datas/myzone10/appli
raw not specified
type: lofs
options: []
net:
address: 192.xx.xx.xx
physical: ce0
defrouter not specified

J'utilise ici deux montages lofs pour stocker les données utilisateurs de ma zone solaris 10. Il ne faut oublier de les récupérer lors de la migration.

# zfs list -r myzone10
NAME USED AVAIL REFER MOUNTPOINT
myzone10 105G 17.2G 10.9G /zones/myzone10
myzone10/appli 83.6G 17.2G 83.6G /datas/myzone10/appli
myzone10/source 10.3G 17.2G 10.3G /datas/myzone10/source

# zfs snapshot myzone10/appli@now
# zfs snapshot myzone10/source@now
# zfs send myzone10/appli@now > /mnt/appli
# zfs send myzone10/source@now > /mnt/source

Les actions ci-dessous sont à réaliser sur le serveur destination Solaris 11

La première étape est de créer la brandZ Solaris 10 sur le serveur Solaris 11.

# zpool create myzone10 cXtYdZ
# zfs set mountpoint=/zones/myzone10
# chmod 700 /zones/myzone10

# cat /var/tmp/myzone10
create -b
set zonepath=/zones/myzone10
set brand=solaris10
set ip-type=shared
add net
set address=192.xx.xx.xx/xx
set physical=ipmp0
end
exit

# zonecfg –z myzone10 –f /var/tmp/myzone10
# zoneadm list –cv
ID NAME STATUS PATH BRAND IP
0 global running / solaris shared
- myzone10 configured /zones/myzone10 solaris10 shared

Je lance maintenant le chargement des données dans ma brandZ Solaris 10.

# mount –F nfs nfsserver:/myshare /mnt
# zoneadm -z myzone10 install -p -a /tools/myzone10.cpio.gz
Progress being logged to /var/log/zones/zoneadm.20130105T011129Z.myzone10.install
Installing: This may take several minutes...
Postprocessing: This may take a while...
Postprocess: Updating the image to run within a zone
Postprocess: Migrating data
from: myzone10/rpool/ROOT/zbe-0
to: myzone10/rpool/export

Postprocess: A backup copy of /export is stored at /export.backup.20130105T012820Z.
It can be deleted after verifying it was migrated correctly.

Result: Installation completed successfully.
Log saved in non-global zone as /zones/myzone10/root/var/log/zones/zoneadm.20130105T011129Z.myzone10.install

L'installation s'est correctement déroulée. Reste encore quelques modifications à faire pour la finaliser complétement : il nous manque notamment les données contenues dans les différents snapshots.

# zfs list -r myzone10
NAME USED AVAIL REFER MOUNTPOINT
myzone10 34.5G 40.0G 33K /zones/myzone10
myzone10/rpool 34.5G 40.0G 31K /rpool
myzone10/rpool/ROOT 34.5G 40.0G 31K legacy
myzone10/rpool/ROOT/zbe-0 34.5G 40.0G 19.5G /zones/myzone10/root
myzone10/rpool/export 34.5G 40.0G 1.0G /zones/myzone10/root/export
myzone10/rpool/export/home 34.5G 40.0G 14.0G /zones/myzone10/root/export/home

# zfs receive myzone10/rpool/ROOT/zbe-0/appli < /mnt/appli
# zfs receive myzone10/rpool/ROOT/zbe-0/source < /mnt/source

# zfs list -r myserver10
NAME USED AVAIL REFER MOUNTPOINT
myzone10 64.5G 10.0G 33K /zones/myzone10
myzone10/rpool 64.5G 10.0G 31K /rpool
myzone10/rpool/ROOT 64.5G 10.0G 31K legacy
myzone10/rpool/ROOT/zbe-0 64.5G 10.0G 19.5G /zones/myzone10/root
myzone10/rpool/ROOT/zbe-0/appli 64.5G 10.0G 20.0G /appli
myzone10/rpool/ROOT/zbe-0/source 64.5G 10.0G 10.0G /source
myzone10/rpool/export 64.5G 10.0G 1.0G /zones/myzone10/root/export
myzone10/rpool/export/home 64.5G 10.0G 14.0G /zones/myzone10/root/export/home

Et voilà notre migration V2V est terminée. Reste plus que l'activation de la brandZ Solaris 10.

# zoneadm -z myzone10 boot

J'espère que cet article vous incitera aux migrations de vos environnements Solaris 10 dans des brandZ Solaris 10. Sans parler des aspects de consolidation, il existe plusieurs avantages à utiliser un chassis Solaris 11 pour héberger vos zones ou brandZ. En effet vous bénéficier de tous les optimisations kernel présentent dans Solaris 11. Un vrai plus, je vous l'assure...

Pour aller plus loin :