Solaris: Introducción a Resource Management

Lo primero que podemos decir de Resource Management, es uno de los grupos de características menos conocidos de Solaris, puedes preguntarle a cualquier administrador de Solaris sobre este conjunto de herramientas y el 70% de ellos no las habrán utilizando nunca y un 60% ni siquiera saben de qué les estás hablando, creo que merece la pena echar un vistazo a Resource Management porque descubriremos que nos puede ayudar en nuestro día a día.

Desde hace tiempo, en la mayoría de los post que escribo estoy hablando sobre el esfuerzo que nosotros como administradores de sistemas tenemos que realizar para comprender y conocer el SO con el que estamos trabajando. Resource Management es el ejemplo claro en Solaris de que la mayoría de la gente de Sistemas (en general toda la gente) se mueven por modas, actualmente ¿ qué está de moda en el mundo de los sistemas operativos ?, sin duda alguna la respuesta es Virtualización, todo es virtualizable o ser susceptible de ser virtualizado. Los principales fabricantes están trabajando en virtualizar sus productos, sean los que sean, actualmente virtualizar es cool (empleando un termino anglosajón). Mi opinión personal es que la virtualización nos puede ayudar a resolver muchos de nuestros problemas, pero en muchos casos, el desconocimiento provoca que se emplee una solución de virtualización en un ámbito que no es necesario.

En el ámbito de los sistemas operativos, la virtualización se ha convertido en sinónimo de levantar varias máquinas virtuales, cada una con su propio SO, en la misma máquina física. La razón es aprovechar de una forma mas eficiente los recursos disponibles en el sistema, hay casos en los que la afirmación anterior tiene sentido, pero en otros no. Hay casos en los que no es mejor disponer de N sistemas operativos corriendo sobre la misma máquina, esto supone un gasto innecesario de recursos, por ejemplo, tiempo de CPU dedicado a la ejecución de los distintos kernels.

Hay casos en los que disponer de un solo SO y gestionando de forma eficiente los recursos disponibles en el sistema nos dará una ventaja objetiva sobre el particionado de los recursos disponibles para asignarlos a varios SO corriendo en el mismos sistema.

El propósito en definitiva es gestionar de la manera mas eficiente los recursos disponibles en el sistema para que las aplicaciones los aprovechen de la mejor forma posible, a veces conseguiremos este objetivo utilizando algún tipo de virtualización y otras veces tendremos que gestionar los recursos disponibles, en este último caso es donde podrá ayudarnos Resource Management

Resource Management

Con Solaris podemos virtualizar de varias formas distintas (LDom, Xen, Zonas, etc), pero sin llegar tan lejos, Solaris dispone de una serie de herramientas que nos permiten gestionar de forma muy eficiente los recursos del sistema, es lo que se conoce como Resource Management. Con este conjunto de herramientas podremos entre otras cosas:

  • Definir grupos de CPUs que se asignaran a los distintos grupos de procesos.
  • Decidir la cantidad de memoria real asignada a un proceso.
  • Definir diferentes parámetros de IPCs para los distintos procesos que corren en el sistema.
  • Definir parámetros como el número de LWP de un proceso, número de ficheros, etc.
  • Crear nuevas políticas para el planificador.

En definitiva con Resource Management tendremos mayor control sobre como nuestros procesos interactúan con los distintos recursos disponibles en la máquina, de esta forma podremos decidir donde los recursos disponibles serán más útiles.Vamos a ver un sencillo ejemplo, una de las posibilidades que nos ofrece Resource Management es la de crear grupos de CPUs, supongamos que disponemos de una máquina con 10 CPUs, algo no demasiado extraño hoy en día. En nuestra nueva máquina vamos a correr 3 aplicaciones, dos de ellas serán muy utilizadas durante todo el día, mientras que la tercera, la mayor parte de la carga la tendrá por la noche cuando se lanzan varios proceso por lotes, justo cuando las otras dos aplicaciones tienen menos carga. Deberíamos realizar la siguiente planificación.

APP A 40% del tiempo de CPU
APP B 40% del tiempo de CPU
APP C 20% del tiempo de CPU

Si queremos garantizar estos porcentajes de tiempos de ejecución, la única forma es crear 3 grupos de CPUs, el primero con 4 CPUs, el segundo con 4 CPUs y el tercero con 2 CPUs. Una vez creados los 3 grupos, ejecutaríamos las 3 aplicaciones cada una con sus propias CPUs, de esta forma garantizamos que el 40% de la máquina está asignado a la aplicación A, otro 40% a la aplicación B y un 20% a la aplicación C.Pero ¿qué ocurre por la noche?, las aplicaciones A y B no necesitan tener asignados tantos recursos, podríamos reducir el número de CPUs asignadas a ambas aplicaciones y aumentar las CPUs asignadas a la aplicación C. Si hiciésemos esto, tendríamos una planificación para el día y otra para la noche.

Projects, task y procesos

Voy a emplear los terminos en ingles Project y Task y no sus correspondiente traducciones, porque pueden perder significado o por lo menos confundir con su traducción. Hasta ahora, el elemento que considerábamos básico en la ejecución de nuestras aplicaciones era el proceso.

El proceso es la unidad básica de ejecución en un sistema Unix. Cuando queremos ejecutar algo en nuestro sistema, se lanza uno o varios procesos, los cuales interactúan entre si y con el resto del SO para desarrollar un propósito determinado. Para nosotros, como administradores de sistemas, el proceso es la unidad con la que trabajamos como consumidor de recursos. La mayoría de los comandos en Unix, miden el uso que realizan los distintos procesos que se están ejecutando en el SO de los recursos disponibles, por ejemplo el comando ps, prstat, pfiles o truss.

Ahora disponemos de dos elementos lógicos, que nos van a permitir agrupar a los distintos procesos que se ejecutan en el SO, para medir el uso que realizan de los recursos, por su puesto también, podremos definir limitaciones concretas en el uso de los recursos. Estos elementos son projects y tasks.

Project

Un project define las características de ejecución de un grupo de procesos. Todos los usuarios del sistema están asignados a uno o varios projects.

Veamos un ejemplo, vamos a crear un project el cual tenga algunas características determinadas, por ejemplo definiremos el número de ficheros abiertos. Lo primero será crear el project user.usrtest1 el cual será asignado por defecto al usuario usrtest1.

root@host # projadd -U usrtest1 user.usrtest1
root@host #

Podemos comprobar que el fichero /etc/project ha sido modificado para añadir una línea con el nuevo project

root@host # cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
user.usrtest1:100::usrtest1::

Este es un ejemplo de un fichero /etc/project, está formado por varias líneas, cada una de las cuales define un project. Cada línea está formada por 6 campos separados por “:“, la descripción de cada uno de los campos es:

  • Nombre del proyecto.
  • ID del proyecto.
  • Descripción.
  • Listado de usuarios que están asignados a este proyecto.
  • Listado de grupos que están asignados al proyecto.
  • Atributos del proyecto

Para modificar el fichero /etc/project, podríamos utilizar el comando vi, pero yo recomiendo que se utilice el comando projmod. Vamos a modificar el project que hemos creado user.usrtest1 para incluir el limite del número de ficheros abiertos.

root@host # projmod -K 'process.max-file-descriptor=(basic,50,deny)'  user.usrtest1
root@host # cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
user.usrtest1:100::usrtest1::process.max-file-descriptor=(basic,50,deny)
root@host #

Como podemos comprobar, el fichero ha sido modificado. Ahora podríamos hacer la prueba de crear una nueva sesión con el usuario de pruebas usrtest1, podemos comprobar con el comando ulimit el valor límite del campo open files. Con el parámetro -p del comando id, obtenemos la lista de los projects a los que pertenece el usuario.

bash-3.00$ id -p
uid=116(usrtest1) gid=1(other) projid=100(user.usrtest1)
bash-3.00$
bash-3.00$
bash-3.00$ ulimit -a
core file size        (blocks, -c) unlimited
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
open files                    (-n) 50
pipe size          (512 bytes, -p) 10
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 29995
virtual memory        (kbytes, -v) unlimited
bash-3.00$

La salida del comando ulimit -a comprobamos que efectivamente el limite de ficheros abiertos es ahora de 50.

Si queremos cambiar el valor de ficheros abiertos del project user.usrtest1 de 50 a 200, volvemos a utilizar el comando projmod

root@host # projmod -K 'process.max-file-descriptor=(basic,200,deny)'  user.usrtest1

Este cambio solo tendrá efecto cuando se vuelva a realizar un login o un su con el usuario usrtest1.

bash-3.00$ id -p
uid=116(usrtest1) gid=1(other) projid=100(user.usrtest1)
bash-3.00$
bash-3.00$
bash-3.00$ ulimit -a
core file size        (blocks, -c) unlimited
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
open files                    (-n) 50
pipe size          (512 bytes, -p) 10
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 29995
virtual memory        (kbytes, -v) unlimited
bash-3.00$
bash-3.00$
bash-3.00$ su - usrtest1
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
bash-3.00$
bash-3.00$ id -p
uid=116(usrtest1) gid=1(other) projid=100(user.usrtest1)
bash-3.00$
bash-3.00$
bash-3.00$ ulimit -a
core file size        (blocks, -c) unlimited
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
open files                    (-n) 200
pipe size          (512 bytes, -p) 10
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 29995
virtual memory        (kbytes, -v) unlimited
bash-3.00$

También tenemos la posibilidad de cambiar los valores de ciertos límites en caliente, sin la necesidad de volver a realizar un login/su, pero estos cambios, si no quedan reflejados en el fichero /etc/project, se perderán una vez terminada la sesión en la que fueron modificados. Para cambiar el caliente los límites utilizaremos el comando prctl

root@host # prctl
prctl: no arguments specified
usage:
    Report resource control values and actions:
        prctl [-P] [-t [basic | privileged | system]
        [-n name] [-i process | task | project | zone] id ...
        -P space delimited output
        -t privilege level of rctl values to get
        -n name of resource control values to get
        -i idtype of operand list
    Manipulate resource control values:
        prctl [-t [basic | privileged | system]
        -n name [-srx] [-v value] [-p pid ] [-e | -d action]
        [-i process | task | project | zone] id ...
        -t privilege level of rctl value to set/replace/delete/modify
        -n name of resource control to set/replace/delete/modify
        -s set new resource control value
        -r replace first rctl value of matching privilege
        -x delete first rctl value of matching privilege, value, and
           recipient pid
        -v value of rctl to set/replace/delete/modify
        -p recipient pid of rctl to set/replace/delete/modify
        -e enable action of first rctl value of matching privilege,
           value, and recipient pid
        -d disable action of first rctl value of matching privilege,
           value, and recipient pid
        -i idtype of operand list

Para nuestro ejemplo, vamos a cambiar el valor del límite process.max-file-descriptor, este límite afecta a procesos por lo que solo podremos cambiarlo si facilitamos un proceso. Vamos a ver cual es el PID del task con el que estamos haciendo las pruebas.

bash-3.00$ echo $$
12690
bash-3.00$

Ahora ejecutamos el comando prctl.

root@jcapp03 # prctl  -t basic   -v 300 -n process.max-file-descriptor    -i  process 12690
root@jcapp03 #

Si ejectuamos el comando ulimit en la sesión que teníamos abierta veremos como se ha modificado en caliente el valor de open files.

bash-3.00$ echo $$
12690
bash-3.00$
bash-3.00$
bash-3.00$ ulimit -a
core file size        (blocks, -c) unlimited
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
open files                    (-n) 300
pipe size          (512 bytes, -p) 10
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 29995
virtual memory        (kbytes, -v) unlimited
bash-3.00$

Resource Control

En la siguiente tabla podemos ver la lista de controles. Cada uno de estos controles actúan sobre procesos, projects, tasks o zonas, dependiendo de qué recursos estemos intentando controlar.

process.max-port-events Número máximo de eventos por puerto.
process.max-msg-messages Número máximo de mensajes en una cola.
process.max-msg-qbytes Número máximo de bytes de un mensaje.
process.max-sem-ops Número máximo de operaciones por llamada semop()
process.max-sem-nsems Número máximo de semáforos por set de semáforos.
process.max-address-space Tamaño máximo en bytes del espacio de direcciones del proceso.
process.max-file-descriptor Número máximo de descriptores de fichero.
process.max-core-size Tamaño máximo en bytes de los ficheros core
process.max-stack-size Tamaño máximo del stack del proceso.
process.max-data-size Tamaño máximo en bytes del heap del proceso.
process.max-file-size Tamaño máximo en bytes del desplazamiento en escritura en un fichero
process.max-cpu-time Tiempo máximo de CPU en segundos disponibles para el proceso.
task.max-cpu-time Tiempo máximo de CPU en segundos disponibles para la tarea.
task.max-lwps Número máximo de LWP de la tarea.
project.max-contracts Número máximo de contracts permitidos en un proyecto.
project.max-locked-memory Tamaño máximo en bytes de memoria bloqueada.
project.max-port-ids Número máximo de puertos de eventos.
project.max-shm-memory Tamaño máximo de memoria compartida en bytes.
project.max-shm-ids Número máximo de IDs de memoria compartida.
project.max-msg-ids Número máximo de IDs de mensajes.
project.max-sem-ids Número máximo de IDs de semáforos.
project.max-crypto-memory Tamaño máximo en bytes de memoria del kernel utilizada para operaciones de encriptación.
project.max-tasks Número máximo de tareas de un proyecto.
project.max-lwps Número máximo de LWP de un proyecto.
project.cpu-cap Cantidad máxima de recursos de CPU asignado a un project
project.cpu-shares  
zone.max-swap  
zone.max-locked-memory  
zone.max-shm-memory  
zone.max-shm-ids  
zone.max-sem-ids  
zone.max-msg-ids  
zone.max-lwps  
zone.cpu-cap  
zone.cpu-shares  

Taks

Cada vez que se inicia una sesión, dependiendo de quién la haya realizado y a qué proyectos pertenezca, se lanza una tarea (task), cada tarea podrá ejecutar tantos procesos como desee. De echo cada vez que entras en el sistema mediante un login se lanza una tarea, la cual estará asociada al project que tenga asignado el usuario que ha realizado el login.

El comando newtask permite entre otras cosas crear nuevas task y lo que es mas interesante mover a procesos que ya están corriendo, dentro de una nueva task. En principio a esto no se le ve mucha utilidad hasta que no se comience a trabajar con prohects y task, pero como ejemplo que ilustre la utilidad de newtask, podemos crear un nuevo project y mover algunos procesos de un project al nuevo que hemos creado, sin tener que parar los procesos.

No te preocupes si no le ves demasiada utilidad tanto al comando newtask, como al concepto de tener tasks, cuando comiences a trabajar con la gestión de recursos comprenderás lo útil que es mover procesos de un project a otro, cambiando los controles definidos y asignando recursos en caliente

Pools

Los Pools son recursos lógicos que definen una serie de recursos físicos, los cuales serán asignados a uno o varios procesos. Un Pool se asocia a uno o varios projects, cada Pool está formado por un Pset y cada Pset tiene asignadas una o varias CPUs del sistemas. Un CPU solo puede estar asociada a un Pset.

La siguiente imagen muestra un ejemplo de la relación entre Projects, Pools, Psets y CPU, la imagen pertenece a la captura de pantalla de la aplicación EasyRC del proyecto phpEasyTools



El primer paso para comenzar a trabajar con los Pools es comprobar que está activado el servicio, podemos utiliza el comando pooladm

root@host02 # pooladm
pooladm: couldn't open pools state file: Facility is not active
root@host02 #
root@host02 # pooladm -h
pooladm: illegal option -- h
Usage:  pooladm [-n] [-s] [-c] [filename]
Usage:  pooladm [-n] -x
Usage:  pooladm -d | -e

Con el parámetro -e del comando pooladm podemos habilitar el servicio.

root@host02 #
root@host02 # pooladm -e
root@host02 #
root@host02 # pooladm

system default
        string  system.comment
        int     system.version 1
        boolean system.bind-default true
        string  system.poold.objectives wt-load

        pool pool_default
                int     pool.sys_id 0
                boolean pool.active true
                boolean pool.default true
                int     pool.importance 1
                string  pool.comment
                pset    pset_default

        pset pset_default
                int     pset.sys_id -1
                boolean pset.default true
                uint    pset.min 1
                uint    pset.max 65536
                string  pset.units population
                uint    pset.load 305
                uint    pset.size 96
                string  pset.comment

                cpu
                        int     cpu.sys_id 101
                        string  cpu.comment
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 100
                        string  cpu.comment
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 103
                        string  cpu.comment
                        string  cpu.status on-line
...

Una vez activado el servicio, con el comando pooladm sin parámetros, podemos ver la configuración actual. Disponemos de varios comandos que nos ayudarán en la administración de los pools que creemos.

poolstat nos devuelve una sencilla salida sobre el estada de los distintos Pools que tengamos configurados en el sistema.

root@host02 # poolstat
                              pset
 id pool                 size used load
  4 prueba1                 6 0.00 0.00
  1 pool_bd10des            7 0.00 1.50
  0 pool_default            6 0.00 0.05
  3 pool_prueba2            7 0.00 0.00
  2 pool_prueba             6 0.00 0.00

poolbind nos permite asociar, procesos, tareas y projects a un Pool sin tener que reiniciar.

root@host02 # poolbind -h
poolbind: illegal option -- h
Usage:  poolbind -p pool_name [-i pid | -i taskid | -i projid | -i zoneid] id ...
        poolbind -q pid ...
        poolbind -Q pid ...
root@host02 #

El comando más interesante de todos los que tenemos disponibles para trabajar con nuestros Pools es poolcfg, que nos permite crear, modificar y eliminar los distintos pools que estén configurados en el sistema. Tenemos dos formas de trabajar con poolcfg, utilizando el fichero de configuración o trabajando directamente con la configuración activa, en este último caso es importante almacenar la configuración activa al fichero de configuración, para evitar que los cambios que hemos realizado se pierdan en el siguiente reinicio.

root@host02 # pooladm -s

Con esta operación actualizaremos el fichero de configuración /etc/pooladm.conf, como la mayoría de los ficheros de configuración de Solaris 10, este fichero almacena la configuración en formato XML por lo que si no eres un experto en XML te aconsejo utilizar el comando poolcfg para las modificaciones, ya que si el sistema no puede leer este fichero no podrá cargar las modificaciones.

Aplicando lo aprendido

Vamos a ver en pocos pasos como podemos crear de una forma sencilla un pool, asignarle un Pset y por último asignar uno de los projects al nuevo pool.

root@host02 # poolcfg -c 'create pool pool_prueba'
root@host02 # pooladm -d
root@host02 # pooladm -e
root@host02 # pooladm | more

system default
        string  system.comment
        int     system.version 1
        boolean system.bind-default true
        string  system.poold.objectives wt-load

        pool pool_prueba
                int     pool.sys_id 1
                boolean pool.active true
                boolean pool.default false
                int     pool.importance 1
                string  pool.comment
                pset    pset_default

        pool pool_default
                int     pool.sys_id 0
                boolean pool.active true
                boolean pool.default true
                int     pool.importance 1
                string  pool.comment
                pset    pset_default

Destruimos el nuevo pool que hemos creado, pero solo de la configuración activa y no del fichero de configuración.

root@host02 # poolcfg -dc 'destroy pool pool_prueba'
root@host02 #
root@host02 # pooladm | more

system default
        string  system.comment
        int     system.version 1
        boolean system.bind-default true
        string  system.poold.objectives wt-load

        pool pool_default
                int     pool.sys_id 0
                boolean pool.active true
                boolean pool.default true
                int     pool.importance 1
                string  pool.comment
                pset    pset_default

Actualizamos el fichero de configuración.

root@host02 # pooladm -s

Volvemos a crear el pool pool_pruebas, pero esta vez en la configuración activa.

root@host02 # poolcfg -dc 'create pool pool_prueba'

Creamos un nuevo Pset al que llamaremos pset_p1.

root@host02 # poolcfg -dc 'create pset pset_p1'

Transferimos las CPUs 1 y 2 al nuevo pset pset_p1

root@host02 # poolcfg -dc 'transfer to pset pset_p1(cpu 1; cpu 2)'
poolcfg: cannot transfer component 1 to pset_p1: Invalid configuration

Vamos a comprobar los parámetros con los que se han creado el nuevo pset pset_p1

root@host02 # pooladm | more

...
        pset pset_p1
                int     pset.sys_id 1
                boolean pset.default false
                uint    pset.min 0
                uint    pset.max 0
                string  pset.units population
                uint    pset.load 0
                uint    pset.size 0
                string  pset.comment
...

Tenemos que modificar la variable uint pset.max con un valor mayor de 0.

root@host02 # poolcfg -dc 'modify pset pset_p1(uint pset.max=10)'
root@host02 #
root@host02 # pooladm | more

system default
        string  system.comment
        int     system.version 1
        boolean system.bind-default true
        string  system.poold.objectives wt-load

        pool pool_default
                int     pool.sys_id 0
                boolean pool.active true
                boolean pool.default true
                int     pool.importance 1
                string  pool.comment
                pset    pset_default

        pset pset_p1
                int     pset.sys_id 1
                boolean pset.default false
                uint    pset.min 0
                uint    pset.max 10
                string  pset.units population
                uint    pset.load 0
                uint    pset.size 0
                string  pset.comment

Una vez que hemos modificado uint pset.max 10 podemos transferir las CPUs 1 y 2 desde el pset pset_default a nuestro nuevo pset_p1

root@host02 # poolcfg -dc 'transfer to pset pset_p1(cpu 1; cpu 2)'
root@host02 #
root@host02 # pooladm | more

system default
        string  system.comment
        int     system.version 1
        boolean system.bind-default true
        string  system.poold.objectives wt-load

        pool pool_default
                int     pool.sys_id 0
                boolean pool.active true
                boolean pool.default true
                int     pool.importance 1
                string  pool.comment
                pset    pset_default

        pset pset_p1
                int     pset.sys_id 1
                boolean pset.default false
                uint    pset.min 0
                uint    pset.max 10
                string  pset.units population
                uint    pset.load 0
                uint    pset.size 2
                string  pset.comment

                cpu
                        int     cpu.sys_id 1
                        string  cpu.comment
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 2
                        string  cpu.comment
                        string  cpu.status on-line

El siguiente paso es asociar el pset pset_p1 con el pool pool_prueba

root@host02 #
root@host02 # poolcfg -dc 'associate pool pool_prueba (pset pset_p1)'
root@host02 #
root@host02 # pooladm | more

system default
        string  system.comment
        int     system.version 1
        boolean system.bind-default true
        string  system.poold.objectives wt-load

        pool pool_default
                int     pool.sys_id 0
                boolean pool.active true
                boolean pool.default true
                int     pool.importance 1
                string  pool.comment
                pset    pset_default

        pool pool_prueba
                int     pool.sys_id 3
                boolean pool.active true
                boolean pool.default false
                int     pool.importance 1
                string  pool.comment
                pset    pset_p1

        pset pset_p1
                int     pset.sys_id 1
                boolean pset.default false
                uint    pset.min 0
                uint    pset.max 10
                string  pset.units population
                uint    pset.load 0
                uint    pset.size 2
                string  pset.comment

                cpu
                        int     cpu.sys_id 1
                        string  cpu.comment
...

En este punto hemos creado un pset, al que hemos transferido las CPUs 1 y 2, hemos creado un pool al que hemos asociado el pset, ahora ya solo nos queda asociar un project al nuevo pool, solo tenemos que añadir el atributo project.pool en el fichero /etc/project, para nuestro ejemplo he modificado el project user.jjmora.

bash-3.00$ cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
user.jjmora:101:jjmora:jjmora:dba:process.max-sem-ops=(basic,10000,deny);project.pool=pool_pruebas;rcap.max-rss=0;task.max-cpu-time=(basic,111,none)

Desde este momento todos los procesos que cree el usuario jjmora se ejecutarán en el pool pool_pruebas el cual solo tiene asignado 2 CPUs.

Conclusión

Espero que la breve descripción que he realizado sobre Resource Management, junto con los ejemplos, sirvan al menos, para despertar vuestra curiosidad, mas adelante intentaré escribir algunos post en los que pueda entra en detalle, mediante ejemplos, de lo útil que es conocer Resource Management sobre todo, porque nos permite de una forma sencilla y rápida poder transferir recursos del sistema de una aplicación a otra, por ejemplo podríamos disponer de varias configuraciones que de forma programada asignen recursos a unos projects u a otros, por la noche a los procesos de backup y bacht y durante el día a los procesos interactivos de los usuarios. La verdad es que las posibilidades son muchas y solo las necesidades de la plataforma que administras podran los límites.

Desde aquí os invito a participar en el proyecto phpEasyTools en el que estamos creado un sencilla interfaz para la gestión de los recurso de Solaris.

5 Responses

  1. Victor M. Fernandez August 3, 2009 / 8:28 pm

    Buenas, por encima de las modas y tendencias del prologo de tu ultimo articulo es bien cierto y conocido que las herramientas del tipo Resource Manager (no es la única) intentan acotar en la medida de lo posible el consumo de los recursos hardware del sistema. Esto es especialmente idicado en entornos donde los aplicativos posibiliten ser instanciables o puedan existir varias isntalciones en paralelo demandando cada una de ellas los recursos de en este caso el afrition que es el OS.

    El articulo esta muy bien, en cualquier caso mas alla de las opiniones personales o consideraciones subjetivas… es cierto que la virtualización no es unicamente una moda o tendencia y si resuelve problemas clasicos de la gestión de infraestructuras… desde la optima utilización de recursos hasta los planes de contigencia o mas aun de continuidad de negocio pasando por el ahorro energetico tanto fisico como en frigorias en el mundo del CPD.

    Por cierto, no es unico de la distro comercial Sun Solaris. Funciona además en otras distros del proyecto opensolaris como Indiana, Nexenta, Belenix, etc…

    Un saludo.

  2. Victor M. Fernandez August 3, 2009 / 9:35 pm

    Por si a alguien le interesa adjunto un caso concreto con respecto a la gestión de recursos de tipo CPU asociados a diferentes Zonas mediante la agrupación de los mismos por el mecanismo FSS (Fais Shre Scheduler). Lo que entre otras cosas… convertirá a la Zonas en Contenedores.

    Un saludo.

  3. David August 13, 2009 / 1:54 am

    En el tema de la virtualizacion yo creo que tambien es especialmente util para la estabilidad de muchas aplicaciones, en vez que se caiga una maquina con 10 aplicaciones diferentes, se virtualizan maquinas y se deja una aplicacion por por maquina virtual, y asi cada maquina tiene una carga minimina y menos riesgo de fallar y en caso de fallo solo se pierde el servicio de una aplicacion.

  4. Urko November 9, 2009 / 3:12 pm

    Realmente un artículo muy interesante, buen trabajo. Al hilo de estos artículos yo escribí en su día la aplicación más técnica del mismo sobre cómo instalar varias Oracle sobre un mismo motor (http://sparcki.blogspot.com/2009/09/varias-bases-de-datos-oracle-en-una.html), y en él se hace referencia a FSS, project.cpu-shares, etc. … muchas de las cosas que comentas en tú artículo.

    Es cierto que ahora con la Virtualización parece que se soluciona todo “montando” el aplicativo sobre algo virtual, pero qué sucede cuando no puedes, o … si al virtualizar no obtienes el rendimiento necesario?

    Además, también sobre esto hay que tener en cuenta que pierdes (en el caso de Solaris) al Virtualizar sobre Zonas, por ejemplo Dynamic Reconfiguration, aquí tienes otro artículo que escribí sobre el tema
    (http://sparcki.blogspot.com/2009/10/problemas-y-limitaciones-de-oracle-en.html)

    Un Saludo,
    Urko

Comments are closed.