Plataformando el sistema operativo con Ansible

Hoy vamos a recuperar la entrada de como preparar el sitema operativo (en este caaso un OEL 7)para una instalacion de Oracle.

Para esto vamos a usar el role so_check del que podemos encontrar la ultima version en nuestro GitHub

Este Playbok no hace nada del otro mundo, ya que simplemente traslada a Ansible los pasos que llevamos a cabo una y otra vez cada vez que preparamos un servidor, como vereis lo mas complicado del mismo es la sintaxsis.

Veamos el codigo completo y luego lo analizaremos por partes

[code lang=»py»]
# Pamplona 2019
# Playbook which checks if teh hosts has all the requested prereequisites
#
# requires
# env: name of the server which should be in the inventory
# vars/oracle_standard.yaml configuration file with all the deppartment values
# vars/so_[version]_requisites.yaml configuration file with the packages required for this version of the software

– hosts: "{{env}}"
remote_user: ansible
become: yes
become_user: root
tasks:
– fail: msg="Error no server definied, please define the env variable in the job"
when: env is not defined

– name: "Including standard variables"
include_vars:
file: "vars/oracle_standard.yaml"

– name: "Including So {{version}} requisites"
include_vars:
file: "vars/so_{{version}}_requisites.yaml"

– name: Chequeamos the group
group:
name: "{{oracle_group}}"
gid: "{{oracle_gid}}"
state: present
tags: oragroup

– name: Check the oracle user
user:
name: "{{oracle_user}}"
uid: "{{oracle_uid}}"
group: "{{oracle_group}}"
shell: /bin/bash
tags: orauser

– name: check required packages
yum:
name: "{{package_name}}"
state: latest
tags: packages

– name : Kernel values
sysctl:
name: "{{ item.name }}"
value: "{{item.value}}"
state: present
ignoreerrors: yes
sysctl_file: /etc/sysctl.d/30-oracle.conf
with_items: "{{kernel_values}}"
tags: sysctl

##We execute Huge Pages separately
– name: Huge Pages
sysctl:
name: vm.nr_hugepages
value: "{{huge_pages}}"
sysctl_set: yes
state: present
sysctl_file: /etc/sysctl.d/30-oracle.conf
ignoreerrors: yes
tags: huge_pages

– name: Limits para el usuario
pam_limits:
domain: oracle
use_max: yes
limit_type: "{{ item.tipo }}"
limit_item: "{{ item.name }}"
value: "{{item.value}}"
dest: /etc/security/limits.d/30-oracle.conf
with_items: "{{limits}}"
tags: limits

– name: Disable firewall
service:
name: firewalld
state: stopped
enabled: no
tags: firewall

– name: disabling SElinux
selinux:
policy: targeted
state: disabled
tags: SELinux
[/code]

Comprobamos usuarios y grupos

Lo primero que hacemos es la comprobacion de que tenemos los usuarios y grupos que necesitamos.
En nuestro taller usamos la configuracion mas basica , que es oracle:dba para toda la instalacion

Comprobamos los paquetes del sistema operativo

En este bloque comprobamos los paquetes del sistema operativo.
Para ello usuaremos el modulo yum de Ansible con una lista de los paquetes, esta lista los vamos a leer de un fichero de variables en el que tendremos reflejado todo lo necesario para la plataformacion de un servidor para la version especifica de Oracle que tenemos.

El conenido de este fichero refrente a los paquetes es una simple lista
[code lang=»py»]
package_name :
– binutils
– oracleasm
– oracleasm-support
– compat-libcap1
– compat-libstdc++-33
– elfutils-libelf-devel
– fontconfig-devel
– glibc
– glibc-devel
[/code]

Valores del Kernel

El siguiente paso es el configurar los parametros del kernel que queremos.
Para este paso vamos a usar el modulo sysctl, aplicando tantos valores como queramos de nuestro fichero de requerimientos
La sintaxsis de estos requerimientos es

[code lang=»py»]
kernel_values:
– { name: fs.file-max, value: 6815744 }
– { name: kernel.sem, value: "250 32000 100 128" }
– { name: kernel.shmmni, value: 4096 }
[/code]

Huge Pages

Las Huge pages es un parametro del kernel como cualquier otro, podriamos haberlo incluido dentro de los kernel parameters pero a mi personalmente me gusta tenerlo separado .
En nuestro caso no estamos dandole un valor fijo, sino que le asignamos el 60% del total del servidor

[code lang=»py»]
#60 percent huge pages
huge_pages: "{{((0.6 * ansible_memtotal_mb)*1024/2)|round|int }}"
[/code]

Limites

El siguiente paso en la plataformacion del sistema operativo es ajustar los soft y hard limits para el usuario Oracle.
Para esto usaremos el modulo pam_limits. El codigo asociado del fichero de variables es muy similar al que usamos en el kernel y, al igual que haciamos con las huge pages obtendremos alguno de estos valores dinamicamente en funcion de los recursos del servidor que vayamos a plataformar

[code lang=»py»]
limits:
– { tipo: ‘soft’ ,name: ‘nproc’, value: 16384 }
– { tipo: ‘hard’ ,name: ‘nproc’, value: 16384 }
– { tipo: ‘soft’ ,name: ‘memlock’, value: "{{ ((0.9 * ansible_memtotal_mb)*1024)|round|int }}" }
– { tipo: ‘hard’ ,name: ‘memlock’, value: "{{ ((0.9 * ansible_memtotal_mb)*1024)|round|int }}" }
[/code]

Desabilitar SElinux y Firewall

Este ultimo paso es mas bien opcional, ya que no deberia de ser un requisito, pero, en la mayoria de las plataformaciones la seguridad suele estar delegada en los elementos de red y el SELinux se deshabilita, por lo que, lo hemos incluido en nuestro playbook

[code lang=»py»]
– name: Disable firewall
service:
name: firewalld
state: stopped
enabled: no
tags: firewall

– name: disabling SElinux
selinux:
policy: targeted
state: disabled
tags: SELinux
[/code]

Como habeis podido ver,como os comentaba al principio no es nada del otro mundo, simplemente es trasladar a lenguaje de ansible los pasos que llevamos a cabo manualmente 1000 veces .

Como siempre, esta entrada es solamente un taller basico, no dudeis en encontrar la ultima y valida version del role en proyecto provisioning e GitHub

Trabajando con Huge pages

A partir de OEL7 deberiammos de chekquear las transparent huge pages

cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

Igualmente , deberiamos de tenerlo configurado en el grub

sudo cat /boot/grub2/grub.cfg |grep trans
  set kernelopts="root=/dev/mapper/vg_main-lv_root ro console=tty0 no_timer_check biosdevname=0 rd.lvm.lv=vg_main/lv_root net.ifnames=0 transparent_hugepage=never "

Por el contrario, si no las hemos modificado ( situacion no deseada) , aparecera

cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never 

A partir de ahi, para ver las disponibles solo hay que ejecutar

test1$: grep Huge /proc/meminfo
AnonHugePages:    897024 kB
HugePages_Total:     220
HugePages_Free:      220
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

Esto nos indica que teemos 220 paginas de 2048 Kb
Lo que significa que el espacio dedicado sera

Gb = 220*2048/1024/1024

Mas informacion en :

Parametro oculto _query_on_physical

Hoy vamos a ver una de estas entradas que contradicen algunas otras que podemos ver en internet.

Dado lo restrictivo de Oracle con el licenciamiento, seria muy interesante contar con una opcion que nos deshabilitara el Real-Time Query del Dataguard .
Si buscamos por internet, nos encontramos con un parametro oculto llamado _query_on_physical

Si Ejecutamos el comando

alter system set "_query_on_physical"=false scope=spfile;

Deshabilitaremos el Active Dataguard, pero … ¿que dice Oracle de todo esto?
Oracle como siempre dice que nunca debemos de activar parametros ocultos en la base de datos a no ser que sea especificamente recomendado por el equipo de soporte

NOTE: Hidden parameter «_query_on_physical» is NOT an option to prevent Active Data Guard usage. It should NOT be used at all in any version of the Oracle Database.
It is unsupported to be set unless Oracle Support advises it for diagnostic reason

Asi que, ya sabeis, la unica opcion que nos da Oracle para no activarlo es «tener cuidado».

Como siempre, mas informacion en soporte:

  • Which are Supported Methods to Prevent Active Data Guard Usage When License is Not Available? (Doc ID 2269239.1)

kernel.panic_on_oops : Nuevo parametro de la 12c

Hoy vamos a ver otra de estas pequeñas sorpresas de Oracle en las nuevas versiones
En los requisitos de la instalacion de la version 12c de Oracle nos encontramos con la siguiente nota

Note: 
The below Kernel Parameter "panic_on_oops=1" is being Introduced and required
 from 12.1.0.2.0 onwards.
kernel.panic_on_oops=1

Que es lo que hace este parametro del Kernel?
Este parametro simplemente controla el comportamiento del kernec cuando un oops or bug es detectado.

Los valores que puede tomar es:

  • 0: INtenta continuar la operacion
  • 1: Entra en panic , ademas de este panica, si el sysctl es distnto de cero, entonces el servidor se reiniciara

Como veis, un parametro bastante inocuo… hasta que buscamos la causa de por que el servidor se ha reiniciado

Nuevas funcionalidades 12c: PGA_AGGREGATE_LIMIT

Hoy vamos a ver una entrada sencilla sobre una nueva funcionalidad de la 12c , el parámetro PGA_AGGREGATE_LIMIT

Desde la versión 9i Oracle ha apostado por la gestión automática de la memoria, uno de los problemas que generaba Al motor la gestión total de la configuración del tamaño de la PGA y SGA es que el motor podía llegar a configuraciones donde el espacio asignado a la PGA fuese muy alto, repercutiendo sobre la SGA y produciendo un exceso de paginación en la base de datos.

Como han solucionado esto ?

Sencillamente han introducido un parámetro nuevo llamado PGA_AGGREGATE_LIMIT

Este nuevo parámetro va a ser un límite del tamaño total de las PGAs de la base de datos, al contrario de lo que ocurria con PGA_AGGREGATE_TARGET que actuaba como valor de referencia , el nuevo PGA_AGGREGATE_LIMIT actúa como límite , y no solo no dejará que este valor se sobrepase, sino que eliminará sesiones que estén usando mas memoria PGA con el nuevo error ora
ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT

¿Cual es el patrón que usa oracle para matar las sesiones

El proceso de background CKPT comprueba cada tres segundos si la cantidad de memoria usada excede el parámetro PGA_AGGREGATE_LIMIT, si este límite es excedido Oracle hará lo sigiuiente

  • Las llamadas de las sesiones que están consumiendo mas PGA son abortadas.(untunable PGA memory)
  • Si el tamaño de la PGA sigue por encima del límite, las sessiones y los procesos que mas PGA usan son terminados (untunable PGA memory)
  • Los procesos de SYS y background no se ven afectados por estas reglas

El motor notifica al cliente el problema con un ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT

¿Como se calcula el valor ?

EL PGA_AGGREGATE_LIMIT es un valor dinámico , por lo que puede modificarse en cualquier momento , su valor es calculado de manera automática en el arranque por el motor al mayor de estos tres valores

  • 2 GB
  • 200% of PGA_AGGREGATE_TARGET
  • PROCESSES ( valor del parámetros de incializacion) * 3 MB
  • Nunca excederá al 120% de la memoria física menos el total del tamaño la SGA .

¿Como lo deshabilito?

Si fijamos en el spfile el valor de esta variable a cero, la base de datos se comportará como lo hacía en la version 11g, y no eliminará las sesiones que sobrepasen este límite.
Esto podemos hacerlo con :

alter system set pga_aggregate_limit=0 scope=both; 

Mas información en