Overblog Suivre ce blog
Administration Créer mon blog
7 février 2013 4 07 /02 /février /2013 20:41

 

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 de ce 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és ?

 

> ::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 paasage 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 autre 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éés à 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 passer. 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 pensé à vérifier les dates de création des processus. Les apparences sont quelques fois trompeuses… n'oubliez pas !?

 

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

 

 

Published by gloumps - dans kernel
commenter cet article
4 février 2013 1 04 /02 /février /2013 21:24

 

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.

 

Published by gloumps - dans administration
commenter cet article
1 février 2013 5 01 /02 /février /2013 23:25

 

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étail 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...

 

Published by gloumps - dans kernel
commenter cet article
31 janvier 2013 4 31 /01 /janvier /2013 21:28

 

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 :

Published by gloumps - dans administration
commenter cet article
30 janvier 2013 3 30 /01 /janvier /2013 22:46

 

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 :

Published by gloumps - dans administration
commenter cet article
8 janvier 2013 2 08 /01 /janvier /2013 20:54

 

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 :

 

Published by gloumps - dans administration
commenter cet article
5 décembre 2012 3 05 /12 /décembre /2012 20:40

 

La semaine prochaine, l'équipe de développement Oracle Solaris Zones effectue une petite escapade Européenne. Le groupe d'utilisateurs GUSES (en collaboration avec Oracle) vous propose de les rencontrer. L'évènement débutera par une présentation, suivie d'un échange avec les intervenants, pour se terminer autour d'un repas.

 

Nous vous attendons nombreux !!

 

 

Inscription

 

  • Envoyer un mail à l'adresse suivante : bruno.philippe@orness.com
  • Sujet du mail : INSCRIPTION Soirée Guses
  • Merci d'indiquer : Nom, Prénom, Participation au repas (oui / non)

 

Lieu

  • Lieu de la présentation n'est pas encore défini actuellement
  • Lieu du repas : Casa Paco, 13 rue Bassano, 75008 Paris (reste à confirmer)

 

Agenda

  • 18h00 - 18h30 : Accueil et Introduction
  • 18h30 - 19h30 : Présentations
  • 19h30 - 20h00 : Echanges avec les intervenants
  • 20h30 - 23h00 : Repas et diverses discussions

 

Liens

Published by gloumps - dans divers
commenter cet article
20 novembre 2012 2 20 /11 /novembre /2012 22:06

 

Première partie d'une analyse effectuée sur un système Solaris 10 exécutant plusieurs bases de données Oracle. Les symptômes remontés par l'équipe DBA sont les suivants : temps de réponse long sur plusieurs bases. 

 

Un petit vmstat rapide, pour connaitre grossièrement l’utilisation du serveur.

 

# vmstat 5 100
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
9 0 0 10677368 22372512 680 5482 106 0 0 0 0 25 4 4 4 14735 114426 20380 46 27 27
[…]
23 0 0 9135032 22314120 4792 21638 0 0 0 0 0 1 0 0  0 11118 154028 16758 50 50 0
16 0 0 9137544 22315040 5294 23490 0 0 0 0 0 1 0 0  0 11380 153204 18659 48 52 0
17 0 0 9084960 22258160 2177 10563 0 0 0 0 0 1 0 10 10 9922 137140 14022 43 54 3
24 0 0 9179648 22320080 3362 15628 0 0 0 0 0 1 0 0  0 10750 128918 16896 43 57 0
30 0 0 8850312 22046056 288 2054 0 0 0 0 0 1  0  0  0 10807 99560 14018 31 63 6
126 0 0 8853432 22082880 41 616 0 0 0 0 0  1  0  6  6 5752 31932 6774 10 88 2
661 0 0 8923392 22133776 19 197 0 0 0 0 0  0  0  0  0 2263 5386 1704  3 97  0
465 0 0 8991776 22117088 25 287 0 0 0 0 0  1  0  3  3 2453 8860 2140  4 96  0
46 0 0 8953016 22085792 223 1502 0 0 0 0 0 1  0  0  0 5766 38776 7626 13 86 1
63 0 0 8920736 22079448 109 846 0 0 0 0 0  1  0  0  0 6630 52695 9918 15 83 2
67 0 0 9076624 22190944 1054 7254 0 0 0 0 0 1 0  4 20 5746 97461 7816 33 66 0
53 0 0 8993152 22164344 815 6238 0 0 0 0 0 2  0 176 173 7381 138464 13787 34 66 0
154 0 0 8815312 22116736 37 745 0 0 0 0 0  1  0  0  0 5150 54699 8493 15 85 0
168 0 0 8628120 22079000 22 399 0 0 0 0 0  1  0  0  0 3899 23637 5677 8 92  0
355 0 0 8558232 22016008 23 431 0 0 0 0 0  1  0  4  4 3364 14270 3970 6 94  0
130 0 0 8944384 22119872 949 6035 0 0 0 0 0 1 0  0  0 5608 64746 5932 23 77 0
94 0 0 8696336 22046504 73 782 0 0 0 0  0  1  0  4  4 5918 39593 6905 11 89 0
127 0 0 8570488 21995968 53 560 0 0 0 0 0  1  0  0  0 5745 26933 6982 9 91  0
75 0 0 8915344 22101408 531 4554 0 0 0 0 0 1  0  4  4 6366 81465 9546 23 77 0
26 0 0 8900360 22049976 86 1279 0 0 0 0 0  1  0  0  0 8994 95004 14896 28 71 1
36 0 0 8860368 22037360 184 1635 0 0 0 0 0 1  0  0  0 7535 89424 13136 23 77 0
49 0 0 8820896 22127776 22 1026 0 0 0 0 0  1  0  5  5 10203 71434 12679 22 73 5
427 0 0 8719360 22085440 13 157 0 0 0 0 0  1  0 227 205 3164 8480 2555 4 96 0
487 0 0 8812896 22104528 77 717 0 0 0 0 0  1  0  0  0 2769 9668 2381  5 95  0
42 0 0 9051608 22152568 588 4325 0 0 0 0 0 1  0  0  0 7835 82729 11531 30 69 1
151 0 0 9023256 22246008 188 2021 0 0 0 0 0 1 0  4  4 5405 40646 9076 14 86 0
[..]

 

Deux remarques vis-à-vis de ce résultat : d’une part la run queue globale est complètement saturée, d’autre part la répartition user/system est de 1 pour 3. Qu’une utilisation system soit supérieur à une utilisation user ne me choque pas forcément, tout dépend des applications, cependant dans mon cas (bases de données Oracle), ce ratio ne me plait pas.

 

Voyons voir qui utilise tout ce temps kernel.

 

# dtrace -n 'profile-997hz /arg0/ { @[execname] = count(); }'
dtrace: description 'profile-1001hz ' matched 1 probe
^C 
[…]
  pgrep                               156
  nmupm                               164
  dtrace                              166
  emdctl                              195
  check_bnp_proces                    225
  tnslsnr                             638
  fsflush                             846
  sldrm_coll                         1182
  perl                               7639
  sched                              9911
  oracle                            17735
  emagent                           26944

 

Intéressant, le temps system est utilisé majoritairement par l’agent Grid d’Oracle (emagent). Détaillons d’un peu plus près les fonctions du kernel sollicitées.

 

# dtrace -n 'profile-997hz /arg0/ { @[func(arg0)] = count(); }'
dtrace: description 'profile-997hz ' matched 1 probe
^C 
[…]
  unix`bzero                                437
  unix`_resume_from_idle                    446
  genunix`mstate_aggr_state                 448
  genunix`avl_walk                          502
  FJSV,SPARC64-VI`cpu_smt_pause             549
  unix`page_lookup_create                   625
  unix`mutex_exit                           870
  unix`utl0                                 877
  FJSV,SPARC64-VI`cpu_halt_cpu             1311
  unix`page_exists                         1765
  unix`mutex_delay_default                 2801
  FJSV,SPARC64-VI`copyout_more             2934
  unix`page_trylock                        3246
  unix`mutex_enter                         5078

 

Le temps kernel est utilisé principalement à la gestion de lock (mutex). Existe t'il une relation entre ces locks et l’agent Grid ?

 

# dtrace –n ‘lockstat::mutex_enter: { @[execname] = count(); }’
dtrace: description 'lockstat::mutex_enter: ' matched 3 probes
^C
[…]
  dtrace                    34218
  sh                        66256
  fsflush                   104986
  sldrm_hist                186238
  nmupm                     294968
  emdctl                    791171
  sched                     861038
  sldrm_coll               1250578
  tnslsnr                  2617337
  perl                     3111793
  oracle                  13825389
  emagent                 15498584

 

A priori oui, il existe une relation entre la forte utilisation kernel (mutex) et l'agent Grid (mais pas seulement). Analysons d’un peu plus près la stack de l'agent Grid au moment des locks.

 

# dtrace –n ‘lockstat::mutex_enter: /execname == “emagent”/ { @[stack()] = count() } \
tick-60s { trunc(@,5); exit(0); }’
dtrace: description 'lockstat::mutex_enter: ' matched 3 probes
[…]
              unix`page_trylock+0x38
              unix`page_trylock_cons+0xc
              unix`page_get_mnode_freelist+0x19c
              unix`page_get_replacement_page+0x30c
              unix`page_claim_contig_pages+0x178
              unix`page_geti_contig_pages+0x618
              unix`page_get_contig_pages+0x160
              unix`page_get_freelist+0x430
              unix`page_alloc_pages+0x110
              genunix`anon_map_privatepages+0xa4
              genunix`anon_map_getpages+0xad0
              genunix`segvn_fault_anonpages+0x32c
              genunix`segvn_fault+0x530
              genunix`as_fault+0x4c8
              unix`pagefault+0xac
              unix`trap+0x910
              unix`ktl0+0x48
              genunix`poll_common+0x5c8
              genunix`pollsys+0xf8
              unix`syscall_trap32+0xcc
           114469

              unix`page_trylock+0x38
              unix`page_trylock_contig_pages+0x94
              unix`page_geti_contig_pages+0x5f4
              unix`page_get_contig_pages+0x160
              unix`page_get_freelist+0x430
              unix`page_alloc_pages+0x110
              genunix`anon_map_privatepages+0xa4
              genunix`anon_map_getpages+0xad0
              genunix`segvn_fault_anonpages+0x32c
              genunix`segvn_fault+0x530
              genunix`as_fault+0x4c8
              unix`pagefault+0xac
              unix`trap+0xd50
              unix`utl0+0x4c
           125499 

              unix`page_trylock+0x38
              unix`page_trylock_cons+0xc
              unix`page_get_mnode_freelist+0x19c
              unix`page_get_replacement_page+0x30c
              unix`page_claim_contig_pages+0x178
              unix`page_geti_contig_pages+0x618
              unix`page_get_contig_pages+0x160
              unix`page_get_freelist+0x430
              unix`page_alloc_pages+0x110
              genunix`anon_map_privatepages+0xa4
              genunix`anon_map_getpages+0xad0
              genunix`segvn_fault_anonpages+0x32c
              genunix`segvn_fault+0x530
              genunix`as_fault+0x4c8
              unix`pagefault+0xac
              unix`trap+0xd50
              unix`utl0+0x4c
         17880348

 

En observant rapidement le résultat, on constaque que les locks proviennent d’allocation de pages mémoire !? Si on regarde un peu plus dans le détail, on constate quelque chose d’intéressant : le système tente d’allouer des pages mémoire de manières contiguës (fonction page_get_contig_pages). Il s’agit « normalement » d’une optimisation du système Solaris (évite la fragmentation mémoire, impact sur les mécanismes de translation d'adresses). Dans notre cas, cela semble pénaliser le fonctionnement du système.

 

Une petite explication du Support Oracle Solaris sur ce sujet.

 

The "Large Page Out Of the Box" (LPOOB) feature of the Oracle Solaris 10 memory management, first implemented in Oracle Solaris 10 1/06 (Update 1), can lead to performance problems when the system runs out of large chunks of free contiguous memory. This is because the Oracle Solaris 10 kernel by default will attempt to relocate memory pages to free up space for creating larger blocks of contiguous memory. Known symptoms are high %system CPU time in vmstat, high number of cross calls in mpstat, and Oracle calling mmap(2) to /dev/zero for getting more memory.

 

Il est possible de changer ce type de fonctionnement par défaut (on alloue des pages sans ce soucier de l’emplacement contiguës de celles-ci) en modifiant le paramètre kernel pg_contig_disable. Petite remarque : ce paramètre influence uniquement la mémoire PGA de la base de données Oracle (pas d'influence sur la mémoire SGA).

 

Testons rapidement la modification de ce paramètre sur notre système.

 

# mdb –kw
Loading modules: [ unix genunix specfs dtrace zfs sd mpt px ssd fcp fctl qlc mpt_sas ip hook neti sctp arp usba md cpc random crypto fcip logindmux ptm ufs sppp nfs lofs ipc ]
> pg_contig_disable/X
pg_contig_disable:
pg_contig_disable:              0              
> pg_contig_disable/W 1
pg_contig_disable:              0               =       0x1
> pg_contig_disable/X
pg_contig_disable:
pg_contig_disable:              1
> ::exit

 

# vmstat 5 30
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 10645464 22354816 680 5481 104 0 0 0 0 25 4 4 4 14733 114929 20416 46 27 27
8 0 0 8071552 21199136 865 6976 0 0 0 0 0  1  0  0  0 14630 138815 26507 54 45 1
13 0 0 7960624 21162752 898 6521 0 0 0 0 0 1  0  0  0 12945 115064 23913 46 54 0
6 0 0 8017848 21150384 657 6674 0 0 0 0 0  1  0  0  0 14140 128303 25855 54 45 0
8 0 0 7965472 21129192 704 6301 0 0 0 0 0  1  0  7  7 15013 130409 25934 55 44 1
39 0 0 7908096 21067600 678 6408 0 0 0 0 0 1  0  0  0 14324 113376 26509 46 54 0
11 0 0 7936560 21059424 717 6684 0 0 0 0 0 1  0  0  0 13445 124844 23464 52 47 1
4 0 0 7860976 20987424 880 6478 0 0 0 0 0  1  0  0  0 14499 129461 26395 53 46 0
13 0 0 7881128 21004464 660 6154 0 0 0 0 0 2  0  0  0 15000 124875 25740 50 48 2
5 0 0 7824424 20954160 709 5939 0 0 0 0 0  1  0  0  0 14831 138457 28836 54 45 1
9 0 0 7774880 20924240 1080 8938 0 0 0 0 0 1  0  5  5 13451 126547 24567 50 49 0
[…]

 

D'une part, la run queue globale est beaucoup moins saturée et, d'autre part, la répartition user/system semble s'être équilibrée. Reste à savoir si la consomation system provient toujours de l'agent Grid ?

 

# dtrace -n 'profile-997hz /arg0/ { @[execname] = count(); }'
dtrace: description 'profile-997hz ' matched 1 probe
^C
[…]
  nmupm                        439
  init                         541
  perl                        1158
  fsflush                     1165
  collectd                    1679
  sldrm_coll                  2630
  emagent                     4264
  tnslsnr                    10857
  sched                      13906
  oracle                    105798

 

La modification du paramètre pg_config_disable semble améliorer le fonctionnement du serveur. L'agent Grid utilise beaucoup moins les ressources system (une bonne chose). Les temps de réponses sont meilleurs mais... Mais voilà : le temps system reste anormalement élevé pour un serveur hébergeant des bases Oracles.

 

Suite de l'analyse lors d'un prochain article.

 

Published by gloumps - dans kernel
commenter cet article
16 novembre 2012 5 16 /11 /novembre /2012 20:50

 

Petit article sur la configuration du déport Console Série et des interruptions NMI sur les serveurs Dell (gamme PowerEdge Rxx0).

 

 

Configuration d'un déport Console Série

 

La redirection série s’effectue par défaut sur le COM2 pour les serveurs Dell. Il est donc nécessaire d’effectuer quelques modifications dans Solaris si vous souhaitez l’utiliser correctement.

 

Il y a deux paramètres importants lors de la configuration : le numéro du port COM et sa vitesse. Ces valeurs doivent correspondre impérativement à la configuration présente dans le BIOS du serveur. Dans mon cas, la redirection série s’effectue sur le COM2 avec une vitesse de 115200 bauds.

 

Mise à jour de grub

 

# cat /rpool/boot/grub/menu.lst
#pragma ident   "@(#)menu.lst   1.1     05/09/01 SMI"
#
# default menu entry to boot
default 0
[…]

#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title Solaris 10 9/10 s10x_u9wos_14a X86
findroot (pool_rpool,0,a)
kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS,console=ttyb,ttyb-mode="115200,8,n,1,-"
module /platform/i86pc/boot_archive
#---------------------END BOOTADM--------------------
#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title Solaris failsafe
findroot (pool_rpool,0,a)
kernel /boot/multiboot -s -B console=ttyb,ttyb-mode="115200,8,n,1,-"
module /boot/amd64/x86.miniroot-safe
#---------------------END BOOTADM--------------------

 

 

Mise à jour des « boot environment variables »

 

# cat /boot/solaris/bootenv.rc                             
#
# Copyright 2007 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
 
#ident  "@(#)bootenv.rc 1.33    07/03/03 SMI"
#
#       bootenv.rc -- boot "environment variables"
#
setprop ata-dma-enabled '1'
setprop atapi-cd-dma-enabled '0'
setprop ttyb-rts-dtr-off 'false'
setprop ttyb-ignore-cd 'true'
setprop ttya-rts-dtr-off 'false'
setprop ttya-ignore-cd 'true'
setprop ttyb-mode '115200,8,n,1,-'
setprop ttya-mode '9600,8,n,1,-'
setprop lba-access-ok '1'
setprop prealloc-chunk-size '0x2000'
setprop console 'ttyb'

 

 

Modification du manifest console-login.xml

 

L'entrée suivante

 

<propval name='label' type='astring' value='console' />

 

devient

 

<propval name='label' type='astring' value='115200' />

 

 

Modification du module asy

 

# cat /kernel/drv/asy.conf
#
# Copyright (c) 1999 by Sun Microsystems, Inc.
# All rights reserved.
#

#pragma ident   "@(#)asy.conf   1.12    99/03/18 SMI"

interrupt-priorities=12;
name="asy" parent="isa" reg=1,0x2f8,8 interrupts=3;

 

 

Un arrêt + relance du serveur est nécessaire pour valider les modifications. Il vous suffit ensuite de vous connecter au déport console (iDrac) pour valider le bon fonctionnement de la redirection.

 

 

Configuration NMI sur serveurs Dell

 

Sur l’ancienne gamme Dell (tous sauf la gamme gen12), il suffisait d’ajouter le setting ci-dessous dans le fichiers system pour pouvoir interpréter l’interruption NMI envoyée.

 

# grep nmi /etc/system
set pcplusmp:apic_kmdb_on_nmi=1
set pcplusmp:apic_panic_on_nmi=1

 

Pour votre culture, le setting « pcplusmp:apic_kmdb_on_nmi » fonctionne uniquement si le kernel est activé en mode debug (instruction kdb à ajouter dans grub).

 

Etrangement ce setting ne fonctionne plus avec la gamme gen12. Je sais résoudre ce problème sans trop comprendre les raisons subtils du changemennt. En fait le module « pcplusmp » ne semble plus fonctionner (même si vous le charger correctement) pour interpréter les instructions NMI. En recherchant un peu, j’ai decouvert un autre module assez intéressant.

 

# cd /kernel/mach
# ls -l
total 757
drwxr-xr-x   2 root     sys            4 Sep 20 15:04 amd64
-rwxr-xr-x   1 root     sys       137528 May 29 10:30 apix
-rwxr-xr-x   1 root     sys       120824 May 29 10:30 pcplusmp

 

Les deux modules « apix » et « pcplusmp » comportent les mêmes variables nmi.

 

# /usr/ccs/bin/nm ./apix | grep -i nmi
[204]   |       432|         4|OBJT |LOCL |0    |4      |acpi_nmi_ccnt
[205]   |       436|         4|OBJT |LOCL |0    |4      |acpi_nmi_cp
[207]   |       440|         4|OBJT |LOCL |0    |4      |acpi_nmi_scnt
[206]   |       444|         4|OBJT |LOCL |0    |4      |acpi_nmi_sp
[590]   |       476|         4|OBJT |GLOB |0    |4      |apic_kmdb_on_nmi
[549]   |     42121|       176|FUNC |GLOB |0    |1      |apic_nmi_intr
[550]   |         1|         1|OBJT |GLOB |0    |COMMON |apic_nmi_lock
[350]   |       532|         4|OBJT |GLOB |0    |4      |apic_num_nmis
[349]   |       652|         4|OBJT |GLOB |0    |4      |apic_panic_on_nmi
[263]   |         0|         0|FUNC |GLOB |0    |UNDEF  |psm_add_nmintr
[655]   |         0|         0|FUNC |GLOB |0    |UNDEF  |tenmicrosec

 

# /usr/ccs/bin/nm ./pcplusmp | grep -i nmi
[171]   |       376|         4|OBJT |LOCL |0    |4      |acpi_nmi_ccnt
[172]   |       380|         4|OBJT |LOCL |0    |4      |acpi_nmi_cp
[174]   |       384|         4|OBJT |LOCL |0    |4      |acpi_nmi_scnt
[173]   |       388|         4|OBJT |LOCL |0    |4      |acpi_nmi_sp
[491]   |       420|         4|OBJT |GLOB |0    |4      |apic_kmdb_on_nmi
[453]   |     33189|       176|FUNC |GLOB |0    |1      |apic_nmi_intr
[454]   |         1|         1|OBJT |GLOB |0    |COMMON |apic_nmi_lock
[300]   |       476|         4|OBJT |GLOB |0    |4      |apic_num_nmis
[299]   |       596|         4|OBJT |GLOB |0    |4      |apic_panic_on_nmi
[224]   |         0|         0|FUNC |GLOB |0    |UNDEF  |psm_add_nmintr
[549]   |         0|         0|FUNC |GLOB |0    |UNDEF  |tenmicrosec

 

J’ai forcé le chargement du module « apix » (dans le fichier system) pour tester l’interruption NMI.

 

# grep apix /etc/system
forceload: mach/apix
set apix:apic_panic_on_nmi=1

 

Soit on modifie la valeur dynamiquement (après avoir loader le module apix) soit on effectue un petit arrêt + relance pour valider la configuration. J'utilise l'outil ipmitool pour générer l'instruction NMI (via le déport console) depuis un autre serveur (natuellement).

 

# ipmitool -I lanplus -U <user> -H <serveur-sp> power diag

 

 

Il ne s'agit pas de grand chose mais la configuration correct d'un déport console (accessible facilement via ssh et non via une interface graphique !!) et la configuration correct du serveur pour pouvoir, en cas de hang (ou pas), prendre facilement un core sont deux éléments obligatoires pour toute production. Je suis encore surpris de rencontrer certaines productions où ces configurations de bases ne sont pas présentes.

 

 

Pour aller plus loin :

 

Published by gloumps - dans administration
commenter cet article
13 novembre 2012 2 13 /11 /novembre /2012 20:24

 

Petite astuce pour la mise à jour kernel d'un miniroot Solaris 10. Mais avant de commencer, parlons un peu du contexte. Lors d'une migration p2v d'un serveur Sparc vers une Ldom, j'ai rencontré l'erreur suivante lors de l'extraction de l'archive flar.

 

{0} ok boot net - install
Requesting Internet Address for xx:xx:xx:xx:xx:xx
SunOS Release 5.10 Version Generic_147440-01 64-bit
Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved.

 […]

No local customization defined

Extracting archive: flar01

        Extracted    0.00 MB (  0% of 11387.00 MB archive)

could not generate hash

 

ERROR: Could not write to pipe while processing 10.0.0.1:/export/flar/flar01.flar
ERROR: Errors occured during the extraction of flash archive.

The file /tmp/flash_errors contains the list of errors encountered

 

ERROR: Could not extract Flash archive
ERROR: Flash installation failed

 

Solaris installation program exited.

 

# cat /tmp/flash_errors
cannot receive: stream has unsupported feature, feature flags = 0

 

Le bug ZFS (cannot receive: stream has unsupported feature) est corrigé dans la version kernel 147440-21. Il est donc nécessaire de mettre à jour le miniroot (version kernel actuelle du miniroot 147440-01). Si comme moi, vous suivez la procédure indiquée dans la documentation Oracle, l'installation du patch kernel ne fonctionne pas : 

 

# mkdir /JUMPSTART/miniroot /JUMPSTART/miniroot.patch
# cd /export/install/S10_u0811/Solaris_10/Tools
# ./setup_install_server /JUMPSTART/miniroot
Verifying target directory...
Calculating the required disk space for the Solaris_10 product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Copying /boot netboot hierarchy...
Install Server setup complete

 

# /boot/solaris/bin/root_archive unpackmedia /JUMPSTART/miniroot /JUMPSTART/miniroot.patch
# cd /JUMPSTART/miniroot.patch/sbin
# cp rc2 rc2.orig
# cp sulogin sulogin.orig

 

# patchadd -C /JUMPSTART/miniroot.patch /var/tmp/147440-23

Checking installed patches...
Executing prepatch script...
df: (/JUMPSTART/miniroot.patch/var/tmp/patchadd-3259121710) not a block device, directory or mounted resource
Insufficient space in /JUMPSTART/miniroot.patch/var/tmp/patchadd-3259121710 to save old files.
Space required in kilobytes:  206535
Space available in kilobytes:  0

 

Patchadd is terminating.
umount: /JUMPSTART/miniroot.patch/tmp/root/var busy
umount: /JUMPSTART/miniroot.patch/tmp busy
umount: /JUMPSTART/miniroot.patch/mnt busy

 

Le patch n’a pas été installé (problème dans le script de prepatch). Un cas de figure non validé par l’engineering Oracle !? Etonnant !?

 

# umount: /JUMPSTART/miniroot.patch/tmp/root/var
# umount: /JUMPSTART/miniroot.patch/tmp
# umount: /JUMPSTART/miniroot.patch/mnt

 

# mount -F lofs /JUMPSTART/miniroot.patch/var/tmp /JUMPSTART/miniroot.patch/var/tmp

 

Pour contourner ce petit problème j’ai trouvé une petite astuce banale mais qui fonctionne :

 

# patchadd -C /JUMPSTART/miniroot.patch /var/tmp/147440-23

Checking installed patches...
Executing prepatch script...
Installing patch packages...

 

Patch 147440-23 has been successfully installed.
See /JUMPSTART/miniroot.patch/var/sadm/patch/147440-23/log for details
Executing postpatch script...

Patch packages installed:
  SUNWcakr
  SUNWcakr.3
  SUNWcakr.2
  SUNWcar.2
  SUNWckr
  SUNWcsl
  SUNWcslr
  SUNWcsr
  SUNWcsu
[…]

 

C’est légèrement mieux. Non ? Vérifions sommairement la présence du patch dans le miniroot :

 

# cd /JUMPSTART/miniroot.patch/var/sadm/patch
# ls
124337-01  147440-23

 

Encore quelques modifications nécessaires pour finaliser le miniroot :

 

# export SVCCFG_REPOSITORY=/JUMPSTART/miniroot.patch/etc/svc/repository.db
# svccfg -s system/manifest-import setprop start/exec = :true
# svccfg -s system/filesystem/usr setprop start/exec = :true
# svccfg -s system/identity:node setprop start/exec = :true
# svccfg -s system/device/local setprop start/exec = :true
# svccfg -s network/loopback:default setprop start/exec = :true
# svccfg -s network/physical:default setprop start/exec = :true
# svccfg -s milestone/multi-user setprop start/exec = :true

 

# cd /JUMPSTART/miniroot.patch/sbin
# mv rc2.orig rc2
# mv sulogin.orig sulogin

 

# /boot/solaris/bin/root_archive packmedia /JUMPSTART/miniroot /JUMPSTART/miniroot.patch

 

Voilà le miniroot est à jours, reste à savoir si celui-ci est fonctionnel.

 

{0} ok boot net -s
Boot device: /virtual-devices@100/channel-devices@200/network@0  File and args: -s
Requesting Internet Address for xx:xx:xx:xx:xx:xx
SunOS Release 5.10 Version Generic_147440-23 64-bit
Copyright (c) 1983, 2012, Oracle and/or its affiliates. All rights reserved.
Booting to milestone "milestone/single-user:default".
Configuring devices.
Using RPC Bootparams for network configuration information.
Attempting to configure interface vnet1...
Skipped interface vnet1
Attempting to configure interface vnet0...
Configured interface vnet0
Requesting System Maintenance Mode
SINGLE USER MODE
#

 

Le miniroot patché semble fonctionnel. Allez hop, testons avec le flar :

 

{0} ok boot net - install
Boot device: /virtual-devices@100/channel-devices@200/network@0  File and args: -s
Requesting Internet Address for xx:xx:xx:xx:xx:xx
SunOS Release 5.10 Version Generic_147440-23 64-bit
Copyright (c) 1983, 2012, Oracle and/or its affiliates. All rights reserved.

[…]

Processing profile
       - Saving Boot Environment Configuration
       - Opening Flash archive
       - Validating Flash archive
       - Selecting all disks
       - Configuring boot device
       - Configuring / (any)

 

ZFS send stream rpool/ROOT/ABE gets extracted to rpool/ROOT/root
ZFS send stream rpool/export gets extracted to rpool/export

 

Verifying disk configuration
Verifying space allocation

 

Preparing system for Flash install

 

Configuring disk (c0d0)
       - Creating Solaris disk label (VTOC)
       - Creating pool rpool
       - Creating swap zvol for pool rpool
       - Creating dump zvol for pool rpool

 

Beginning Flash archive processing

 

Predeployment processing
16 blocks
32 blocks
16 blocks

 

No local customization defined

 

Extracting archive: flar01
       Extracted    0.00 MB (  0% of 11387.00 MB archive)
       Extracted    1.00 MB (  0% of 11387.00 MB archive)
       Extracted    2.00 MB (  0% of 11387.00 MB archive)
       Extracted    3.00 MB (  0% of 11387.00 MB archive)
[…]
       Extracted 11384.42 MB ( 99% of 11387.00 MB archive)
       Extracted 11385.42 MB ( 99% of 11387.00 MB archive)
       Extracted 11386.42 MB ( 99% of 11387.00 MB archive)
       Extracted 11387.00 MB (100% of 11387.00 MB archive)
       Extraction complete
[…]

 

Rien de plus simple qu'un petit montage lofs pour contourner le problème dans le script de prepatch du kernel. Astuce valable pour le kernel 147440-23, à voir si dans les versions inférieurs (ou suppérieurs), cette erreur est (ou sera) encore présente.

 

 

Ci-joint quelques références sur ce sujet :

 

Published by gloumps - dans administration
commenter cet article