SafeChildren Banner

Havoc Oracle Solaris Experts

martes, 4 de agosto de 2009

Instalación de Oracle 10g en una zona sobre Solaris - Parte 1

Introducción
Existe mucha información de cómo instalar Oracle 10g sobre Solaris, sin embargo, quería hacer un post donde explicar algunos trucos que suelo utilizar yo.

El problema, Licenciamiento de Oracle
Bien, todos sabemos que Oracle se puede Licenciar por usuario y cpu. Hasta aquí todo correcto, pero qué pasa con los equipos CMT (UltraSPARC T1, T2, T2+) que tienen hasta 128 Threads? El problema es que el Sistema computa cada thread como una cpu (aunque realmente no es cierto) y por lo tanto, tenías n micros.

En las primeras versiones de Solaris 10 no existía forma de físicamente particionar el hardware (si que existe a nivel de Hardware, por ejemplo, en la serie M) y por lo tanto, la solución era utilizar resource pool, sin embargo, para Oracle ésto no era válido (si, he puesto era porque han cambiado un poco las cosas).

En la versión Solaris Update 4 se introdujo una nueva propiedad llamada cappable que nos permite limitar de una forma más sencilla los recursos de la zona.

No es que antes no se pudiese, no, lo que sucede es que ahora, es realmente mucho más sencillo habilitar los límites de máximo número de cpu y uso, además según la nota de Metalink 317257.1, es un licenciamiento válido, como se muestra a continuación

To create a Solaris 10 container that fits the licensing requirements set by Oracle, the Solaris system administrator needs to create a resource pool with the desired number of CPUs or cores and bind a zone to this resource pool. Alternatively, the administrator may set up a zone to use dynamic pool with specified CPU maximum limit. The license is driven by the number of CPUs or cores in this pool.

Creación Zona para Oracle
La creación de la Zona no es muy diferente a la creación de una zona como ya expliqué en el post Gestión básica de Zonas, sin embargo, debemos tener en cuenta algunas cosas:

Oracle hace un uso intensivo de los discos, por lo tanto, es necesario hacer visibles los discos como devices y no montados a través de la zona.


Es muy recomendable hacer que las IP sean de tipo exclusive para evitar fallos en el rendimiento.
Para ello, vamos ha configurar la zona, con los siguientes parámetros, en mi configuración los discos están en una SAN con una Emulex, y la máquina tiene dos zonas, gnosis Oracle 10.2.0.4 Production y osiris Oracle 10.2.0.4 Integration. Por ello, la parametrización de cpu-shares es 80 para gnosis y 20 para osiris.


# zonecfg -z gnosis
gnosis: No se ha configurado esa zona
Use 'create' para comenzar a configurar una zona nueva.
zonecfg:gnosis> create
zonecfg:gnosis> set zonepath=/opt/zones/gnosis
zonecfg:gnosis> set autoboot=true
zonecfg:gnosis> add net
zonecfg:gnosis:net> set physical=e1000g0
zonecfg:gnosis:net> set address=10.80.1.7/24
zonecfg:gnosis:net> set defrouter=10.80.1.254
zonecfg:gnosis:net> end
zonecfg:gnosis> add device
zonecfg:gnosis:device> set match=/dev/dsk/c5t600A0B80002AF68E000007324A70F30Ed0s6
zonecfg:gnosis:device> end
zonecfg:gnosis> add device
zonecfg:gnosis:device> set match=/dev/rdsk/c5t600A0B80002AF68E000007324A70F30Ed0s6
zonecfg:gnosis:device> end
zonecfg:gnosis> set scheduling-class=FSS
zonecfg:gnosis> set cpu-shares=80
zonecfg:gnosis> set max-shm-memory=4G
zonecfg:gnosis> verify
zonecfg:gnosis> commit
zonecfg:gnosis> exit
Desde la versión 10 de Solaris, ya no es necesario establecer los valores de max-shm-memory en el archivo /etc/system sin embargo, si el valor de noexec_user_stack a 1. Para ello, vamos a editar el archivo /etc/system de la zona global

# vi /etc/system

* **********************************
* FC Tuning
* *********************************
set ssd:ssd_io_time=0x78
set sd:sd_max_throttle=16

* ***********************************
* Parametros para Tunear el Sistema
* ***********************************

*
* maxusers = Total Memory (In Mb)
*
set maxusers=4096

*
* rflim_fd_max
* Limite de descriptores maximos de archivos abiertos
* por defecto: 1024
*
set rlim_fd_max=8192

*
* rlim_fd_cur
* por defecto: 64
*
set rlim_fd_cur=8192

*
* sq_max_size
* Controla la cola de los drivers (buffer)
* por defecto: 2
* asignado a infinito: 0
*
set sq_max_size=0

*************************************************
* configuracion para el acceso de la memoria *
*************************************************
* Minimo porcentaje que pageout puede consumir
* Default: 4 - Range: 1 .. 80
set min_percent_cpu=6

*************************************************
* permitir accesos de root en la maquina *
*************************************************
set reserved_procs=20

*************************************************
* parametrizacion de oracle 10g2 *
*************************************************
set noexec_user_stack=1
set semsys:seminfo_semmni=100
set semsys:seminfo_semmns=1024
set semsys:seminfo_semmsl=605
set semsys:seminfo_semvmx=32767
************************************************
* debemos poner MAXINT64 en UltraSPARC
* setting this parameter to the maximum possible
* value has no side effects.
* 4096*2*1024*1024
*************************************************
set shmsys:shminfo_shmmax=8589934592
set shmsys:shminfo_shmmni=100
set shmsys:shminfo_shmseg=10

* ya no tiene soporte en el kernel de la sol9
set shmsys:shminfo_shmmin=1
Nota: Como ya he dicho, en Solaris 10, ya no es necesario poner aquí los valores semáforos y segmentos de memoria máximos, sin embargo, yo sigo utilizando algun Solaris 9 y por eso, tengo el system así.

Asignaremos el planificador FSS por defecto a nuestra máquina, rebootaremos para que los cambios se apliquen y concluiremos con la instalación de la zona gnosis y su configuración

Configuración de Número de CPUs y Uso de CPU
Dentro de las nuevas posibilidades de configuración que nos aporta Solaris 10u5, tenemos capped-cpu y dedicated-cpu que son excluyentes es decir, no podemos asignar dedicated y capped de forma simultánea.

Vamos a ver cuándo es interesante capped-cpu y cuando dedicated-cpu. Imaginemos que tenemos una máquina con 4 UltraSPARC IV+, para Solaris existen 8 cpu, y nuestra licencia de Oracle SE es hasta 4 cpus. En esta situación lo que queremos es limitar el número de CPUs visibles a la Zona para ello utilizaremos dedicated-cpu ya que esas 4 cpu asignadas no serán accesibles por ninguna zona más (Realmente, lo que sucede es que se crea un nuevo pset y se binda los procesos de la zona a este pset). Sin embargo, si tengo una máquina con 2 UltraSPARC IIIcu, y al igual que sucede antes, mi licencia es de hasta 4 cpus, lo que me interesa es asignar un valor de capped-cpu para que varias zonas puedan compartir los recursos, siendo 1 un 100% de uso de micro, por lo tanto, si tengo 2 CPUs y quiero que mi zona de Production tenga una CPU y media, asignaré un valor de ncpus=1,50. Utilizando capped-cpu ambas CPUs son visibles para las zonas, sin embargo, sólo podrán utilizar el número de CPUs asignado en ncpus

Conclusión, la principal diferencia entre dedicated-cpu y capped-cpu radica en la visibilidad de las CPUs para las Zonas, con dedicated-cpu sólo serán visibles para la zona asignada, y con capped-cpu todas las zonas verán las CPUs pero podrán utilizar sólo aquel valor asignado en ncpus

Una vez que tengamos claro el tipo de resouce pool que queremos, asignaremos una propiedad u otra, en mi caso he asignado los siguientes valores

Zona Osiris Integration

# zonecfg -z osiris
zonecfg:osiris> add capped-cpu
zonecfg:osiris:capped-cpu> set ncpus=0,75
zonecfg:osiris:capped-cpu> end
zonecfg:osiris> verify
zonecfg:osiris> commit
Zona Gnosis Production

# zonecfg -z gnosis
zonecfg:gnosis> add capped-cpu
zonecfg:gnosis:capped-cpu> set ncpus=1,75
zonecfg:gnosis:capped-cpu> end
zonecfg:gnosis> verify
zonecfg:gnosis> commit
Creación del project, grupo y usuario
Como ye hemos comentado antes, ahora los valores del tamaño máximo de segmento, semáforos, etc. se asignan mediante project de esta forma, es posible modificarlos en caliente. El valor de max-shm-memory será 1/4 de la memoria total del sistema según Metalink
# projadd group.dba
# projmod -sK "process.max-msg-qbytes=(privileged,65536,deny)" group.dba
# projmod -sK "process.max-sem-nsems=(privileged,4096,deny)"group.dba
# projmod -sK "project.max-shm-memory=(privileged,2147483648,deny)" group.dba
# groupadd -g 2010 group.dba
# useradd -s /bin/bash -d /export/home/oracle -m -g dba oracle

Configuración del profile del usuario oracle
Aunque no es necesario, ya que se puede establecer siempre de forma manual, creo que es más recomendable crearlo, yo utilizo siempre el profile para evitar problemas al asignar los ORACLE_HOME u ORACLE_SID

# zlogin osiris
[Conectado a la zona 'osiris' pts/4]
Last login: Tue Aug 4 18:49:24 on pts/4
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
# su - oracle
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$ id -p
uid=2011(oracle) gid=2010(dba) projid=100(group.dba)
$ vi .profile
# asignamos la mascara por defecto
umask 027


# configuracion del path y demas
PATH=$PATH:/usr/local/bin:/usr/sfw/bin:/usr/ccs/bin
export PATH


# configuracion activa
ORACLE_ACTIVE=VOLDEMORT


# usuario de sistema para oracle
ORACLE_SYSTEM_USER=oracle
# version de DB
ORACLE_DB_VERSION=10.2


# directorios de trabajo de oracle
ORACLE_BASE_PATH=/u01/app/${ORACLE_SYSTEM_USER}/${ORACLE_DB_VERSION}/db
ORACLE_HOME=$ORACLE_BASE_PATH
ORACLE_SID=$ORACLE_ACTIVE
export ORACLE_BASE ORACLE_HOME ORACLE_SID


# REV 1.2
OFA_SUPPORT=Yes


# configuracion del path y demas
PATH=$PATH:$ORACLE_HOME/bin:$ORACLE_HOME/OPatch
export PATH


# REV 1.1
ODBCINI=/etc/odbc.ini
ODBCSYSINI=/etc
export ODBCINI ODBCSYSINI


# mostramos la configuracion activa
echo "*****************************************************"
banner ${ORACLE_SYSTEM_USER}
echo "*****************************************************"
echo "ORACLE configurado con:"
echo "ORA_SID: $ORACLE_ACTIVE"
echo "ORA_HOME: $ORACLE_HOME"
if [ -a /etc/odbc.ini ]; then
echo "ODBC_SUPPORT: YES"
echo "+ ODBC_HOME: $ODBCSYSINI"
echo "+ ODBC_FILE: $ODBCINI"
else
echo "ODBC_SUPPORT: ** NO **"
fi
echo "USING_OFA: ${OFA_SUPPORT}"


# finalizamos mirando el correo
MAIL=/usr/mail/${LOGNAME:?}
Crearemos la estructura de directorios para la instalación
# mkdir /u01 /u02 /u03 /u04 /u05
# chown oracle:dba /u0?
# chmod 750 /u0?
Ya tenemos todo preparado para poder comenzar con la instalación de Oracle 10g en nuestra zona de Solaris, puedes continuar con el proceso en la segunda parte de Instalación de Oracle 10g en Solaris - Parte 2



Referencias

3 comentarios:

  1. Hola

    Solo una duda: ¿Porque tienes la sig. configuracion?:

    gnosis: cpu-shares=80 y ncpus=0.75
    osiris: cpu-shares=20 y ncpus=1.75

    ¿No debería ser?:

    gnosis: cpu-shares=80 y ncpus=1.75
    osiris: cpu-shares=20 y ncpus=0.75

    ¿O que concepto no logré entender?

    Gracias

    ResponderEliminar
  2. Hola jflores,

    Oops! Si, tienes razón! La configuración más coherente es la que tu propones -y la que debería poner-

    Es decir,

    Limitamos el uso de CPU con ncpus y, a este límite le damos un peso de FSS 80, tal y como tu dices:

    gnosis: cpu-shares=80 y ncpus=1.75
    osiris: cpu-shares=20 y ncpus=0.75


    Muchas gracias por tu ayuda.

    Un Saludo,
    Urko

    ResponderEliminar
  3. Hola jFlores,

    Corregido! Además, de paso, he mejora un poco la estructura para que en el nuevo formato se lea mejor.

    De nuevo, muchas gracias.

    Un Saludo,
    Urko

    ResponderEliminar