Jeudi 31 janvier 2013 4 31 /01 /Jan /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 :

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

Mercredi 30 janvier 2013 3 30 /01 /Jan /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 :

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

Mardi 8 janvier 2013 2 08 /01 /Jan /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 :

 

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

Mercredi 5 décembre 2012 3 05 /12 /Déc /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

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

Mardi 20 novembre 2012 2 20 /11 /Nov /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.

 

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

Vendredi 16 novembre 2012 5 16 /11 /Nov /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 :

 

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

Présentation

Informations personnelles

  • Passionné d'informatique, je travaille actuellement comme expert système Solaris. Vous trouverez plus de renseignements à mon sujet sur mon profil Linkedin.

Flux RSS

  • Flux RSS des articles

Calendrier

Décembre 2014
L M M J V S D
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
<< < > >>
Créer un blog gratuit sur over-blog.com - Contact - C.G.U. - Signaler un abus - Articles les plus commentés