Cómo obtener las métricas de "Exadata Storage Servers" desde los "Compute nodes"

Por Fernando Simon (OCE) & Deiby Gómez
Publicado en Junio 2015

Hoy en día existen muchos “Exadata Database Machines” como solución en varias organizaciones y los administradores están usando varias herramientas para monitorear el rendimiento y para saber qué es lo que esta sucediendo dentro de cada servidor de almacenamiento o “Cells”, la red, los servidores de bases de datos, entre otros. Sin embargo, existen varias métricas que nos dan información muy importante sobre el trabajo hecho dentro de los servidores de almacenamiento y que nosotros usualmente no sabemos de ellas o simplemente no las usamos.

Nosotros podemos tomar ventaja de todas las métricas que cada servidor de almacenamiento mantiene y podemos usar esa información para entender la carga y el trabajo que estos servidores están realizando, desafortunadamente cuando quieres ver estas métricas tienes que ingresar a cada servidor de almacenamiento para poder estas métricas (ni siquiera Cloud Control muestra toda la información sobre estas métricas). Si eres un administrador de un “Exadata Database Machine Full Rack” tendrás 14 servidores a los cuales tendrás que ingresar, uno por uno. ¡Eso es demasiado tedioso! En este articulo nosotros te mostraremos cómo puedes obtener estas métricas sin estar accediendo a cada servidor de almacenamiento, después de implementar unos cuantos pasos sencillos tu serás capaz de consultar con sentencias SQL toda la información extraída desde los servidores de almacenamiento.

Básicamente los pasos que nosotros realizaremos en este articulo están resumidos en la siguiente imagen:

Enviaremos una sentencia SELECT desde una instancia en un servidor de base de datos, la instancia se comunicará con una tabla externa, la tabla externa llamará a un script que a su vez extraerá la información de las métricas de todos los servidores de almacenamiento. ¡Fácil! ¿no es así?

Resumen de los pasos:

Paso 1 – Crear el Script
Paso 2 – Probar el script
Paso 3 – Crear la tabla externa
Paso 4 – Ajustar la información
Paso 5 – Leyendo los datos

Paso 1 – Crear el Script

La idea que nosotros usaremos en este articulo será muy parecida a la que Christo Kutrovsky usó en su artículo www.pythian.com/blog/whats-in-your-exadata-smart-flash-cache/ en donde él hecha un vistazo a lo que está sucediendo dentro del “FlashCache”.

Nosotros crearemos un script sencillo que usará una tabla externa, luego la tabla externa retornará las métricas desde los servidores de almacenamiento. El script que nosotros usaremos está disponible al final de este articulo llamado “metric-his-US.sh”, este script puede ser modificado y adaptado tanto como tu quieras con el objetivo de cumplir con tus requerimientos. Tienes que poner este script dentro del servidor de base de datos desde donde quieres consultar las métricas. Con el comportamiento de facto del script, los datos retornados son de la última hora de trabajo de cada uno de los servidores de almacenamiento que aparece en el archivo cellip.ora.

Si hechas un vistazo dentro del script encontrarás que hay tres variables importantes con las cuales puedes jugar:

lTxtWindow:             Esta variable es usada para ajustar el valor del tiempo para la recuperación de las métricas.
lTxtWindowType:    Esta variable define la unidad de tiempo, puede ser horas, días o minutos. El valor de facto es horas.
lTxtTMZ:                    Esta variable es usada para definir la zona horaria. Para este ejemplo nosotros usaremos “-03:00”.

Notas importantes:

• El script usa “ssh” para el usuario “grid” para poder acceder dentro de los servidores de almacenamiento. Entonces, un prerrequisito para este script es que “ssh” este configurado en la maquina de Exadata. Usualmente las llaves ssh están ya generadas y solo hace falta copiarlas usando herramientas de Linux como “ssh-copy-id”.

Para asegurarse que la configuración de ssh este funcionando correctamente, puedes intentar acceder a los servidores usando “ssh grid@<IP_or_Hostname>” , si la configuración es correcta tendrías que ser capaz de acceder sin necesidad de especificar ninguna contraseña.

• Si quieres ejecutar el script desde cualquier instancia de base de datos deberás configurar dicho script en con su tabla externa y su tabla física en cada servidor de base de datos. Básicamente tienes que realizar todos los pasos que a continuación te mostraremos en cada servidor de base de datos. Recuerda que si tu instalación está usando roles separados tendrás que configurar el script del “Paso 2” como usuario grid.  

Se puede copiar el script a un directorio específico dentro del servidor de base de datos y dependiendo de tus políticas de seguridad se necesitará alterar o agregar permisos al directorio que se usará para el script. En este articulo (para hacerlo más simple) nosotros usaremos el directorio “/tmp” para alojar el script. El nombre del script dependerá de tus gustos, en este articulo usamos el nombre “metric-his-US.sh”.

Paso 2 – Probar el script

Una vez se haya completado el “Paso 1” se tendrá el script en el directorio “/tmp” y listo para ser ejecutado. El script podrá ser probado en una terminal y el resultado debería ser parecido a la siguiente imagen:

Como se puede ver arriba, la salida de cada métrica de los servidores de almacenamiento son retornados en una única línea y haciendo uso del símbolo “|” como un delimitador de los campos. Este símbolo será usado en el “Paso 3” para darle a los datos un mejor formato.

Paso 3 – Crear la tabla externa

Una vez se haya confirmado que el script del “Paso 2” este retornando los datos apropiadamente, el siguiente paso será  configurar la tabla externa en el servidor de base de datos desde donde se quiere consultar la información de las métricas de los servidores de almacenamiento, recuerda que si quieres consultar dicha información desde cualquier instancia deberás configurar estos pasos también en  cada una de ellas. La tabla externa usará un directorio de Oracle por lo que deberemos ejecutar la siguiente instrucción:

      create  directory metric_cell as '/tmp';

Cuando el directorio ya esté creado, el siguiente paso es crear la tabla externa tomando ventaja de la opción PREPROCESSOR. El orden de las columnas es la misma que el orden de las métricas de Exadata. Tienes que estar consciente que el tipo de todas las columnas es “varchar2” esto fue hecho así para hacer el procedimiento más simple:

create  table metric_cell_hist (
node varchar(150),
nameMetric varchar(150),
alertState varchar(150),
collectionTime varchar(150),
metricObjectName varchar(150),
metricType varchar(150),
metricValue varchar(150),
objectType varchar(150)
)
ORGANIZATION  EXTERNAL
(
TYPE ORACLE_LOADER
  DEFAULT  DIRECTORY metric_cell
ACCESS PARAMETERS
(
RECORDS DELIMITED BY NEWLINE
PREPROCESSOR  metric_cell: 'metric-hist-US.sh'
nologfile
nobadfile
     FIELDS  TERMINATED BY '|'
)
LOCATION ('.')
)
REJECT  LIMIT UNLIMITED;

Ahora serás capaz de ejecutar consultas contra la tabla externa “metric_cell_hist” y podrás recuperar las métricas haciendo uso de esta tabla externa.

Paso 4 – Ajustar la información

Bien, ya somos capaces de obtener datos desde los servidores de almacenamiento pero la estructura que estamos usando tiene los valores en “varchar2” y también cada vez que ejecutemos una consulta contra la tabla externa el script será llamado para poder recuperar los datos. Para mejorar esto realizaremos algunos ajustes para poder tener más flexibilidad.

El siguiente paso que nosotros haremos es crear una tabla física o “heap-organized table” llamada tabMetricHist_1hr en un Tablespace dedicado para almacenar el resultado desde la tabla externa. Tu puedes usar la siguiente sentencia para crear la tabla, la sentencia como podrás ver tiene algunas funciones de conversión de tipos. La primer conversión es en la columna “collectiontime” para convertirla al tipo “DATE” y la segunda conversión es sobre la columna “metricvalue” para poder separar los valores enteros de la unidad.

CREATE TABLE  tabMetricHist_1hr TABLESPACE DTITBS
AS
select mch.node AS cellServer
, mch.namemetric AS metric
, mch.alertstate AS metricState
, TO_DATE(SUBSTR(mch.collectiontime, 0,  19), 'RRRR-MM-DD"T"HH24:MI:SS') as collectionMoment 
, mch.collectiontime
, mch.metricobjectname AS objectName
, mch.metrictype AS metricType
, CASE 
WHEN INSTR(mch.metricvalue, ' ') != 0 THEN SUBSTR(mch.metricvalue, 0,  INSTR(mch.metricvalue, ' '))
ELSE mch.metricvalue
END AS collectedValue
, mch.metricvalue
, CASE 
WHEN INSTR(mch.metricvalue, ' ') != 0 THEN SUBSTR(mch.metricvalue,  INSTR(mch.metricvalue, ' ') + 1, 50)
ELSE 'N/A'
END AS metricUnit
, mch.objecttype  AS objectType
from metric_cell_hist mch;

Antes de seguir avanzando en el tema, nos gustaría darte una explicación, tienes que estar consiente que algunas métricas de los servidores de almacenamiento son acumulables. Esto significa que si nosotros recolectamos las métricas a las 03:00PM y los servidores de almacenamiento han realizado para entonces 100,000 IOPS el valor que obtendremos es precisamente 100,000. Sin embargo, si nosotros volvemos a recolectar las métricas a las 03:10PM (10 minutos después) y los servidores de almacenamiento han hecho adicionalmente otros 100,000 IOPS, entonces, el valor que obtendremos será 110,000 IOPS en lugar de únicamente recibir 10,000 porque la métrica es acumulable. Si tu quieres ver el valor real de la ultima hora y con eso evitar sorpresas al ver valores muy grandes en las métricas tendrás que hacer algunos ajustes que están fuera del alcance de este articulo.
Ahora con la tabla física tu podrás hacer más cosas que la ultima vez cuando solamente teníamos la tabla externa. Ahora puedes crear índices para mejorar tus consultas o realizar las transformaciones que tu desees para obtener los datos que tu necesites. Si prefieres tener un separador de los decimales diferente a los que se están mostrando puedes removerlos y usar el símbolo que desees. Los siguientes dos comandos crean dos columnas para ayudar a convertir los valores de “varchar2” a “numero”:

ALTER TABLE tabMetricHist_1hr 
ADD collectedValue_num DECIMAL(32, 8);

ALTER TABLE tabMetricHist_1hr 
ADD collectedValue_fixed DECIMAL(32, 8); 

Recuerda que todas estas modificaciones es solamente para mostrarte que puedes hacer los ajustes que tu quieras y adaptar los datos a tus requerimientos, los ajustes que se muestran en este articulo no son obligatorios. Las siguientes sentencias realizan una conversión de los valores de las métricas (en nuestro caso remueve el separador “,”). La tercer sentencia no copia los valores de las métricas que son acumulables. Si tu no quieres hacer esto puedes remover la clausula “WHERE” de la tercer sentencia. También puedes hacer uso del script “fixCumulativeMetric.sql” para modificar las métricas acumulables.

UPDATE tabMetricHist_1hr mh  SET collectedValue_num = TO_NUMBER(REPLACE(mh.collectedValue, ','));

UPDATE tabMetricHist_1hr tmh  SET tmh.collectedValue_fixed = 0 WHERE tmh.collectedValue_num = 0;

UPDATE tabMetricHist_1hr mh  SET collectedValue_fixed = collectedValue_num WHERE tipometrica != 'Cumulative';

Todas las columnas adicionales y las conversiones de los tipos pueden hacerse durante la creación de la tabla física, nosotros lo hicimos separadamente para poder explicar a mas detalle la parte de “ajustes”, sin embargo, te recomendamos hacer estos ajustes en el momento de creación de la tabla.

Paso 5 – Leyendo los datos

Después de pasar por todos los pasos anteriores ahora estamos listos para poder iniciar a ejecutar consultas contra nuestra tabla debidamente ajustada. Como dijimos anteriormente, el comportamiento de facto de nuestro script es retornar solo la ultima hora de las métricas, pero tu puedes consultar los datos de hasta 7 días atrás. Las métricas de los servidores de almacenamiento son calculadas cada minuto. Te recomendamos leer la guía de usuario del software de Oracle Exadata para poder entender más a fondo lo que significa cada métrica y para conocer otras métricas que nosotros no consideramos en este artículo pero que también son muy útiles.

Por ejemplo, para empezar a jugar con nuestra configuración, puedes crear una consulta como la siguiente. Esta consulta retornará el consumo de IOPS en el grupo de  FlashCashe por base de datos, esta consulta fue ejecutada el 02/09/2015 a las 02:45:00 PM usando el valor de la métrica DB_FC_IO_RQ_SEC:

select  tmh.metric
, ROUND(SUM(tmh.collectedValue_fixed),  0) as value
,  tmh.metricUnit
,  tmh.objectName
,  to_char(tmh.collectionMoment, 'DD/MM/RRRR HH24:MI') as moment
FROM  tabMetricHist_1hr tmh
WHERE  tmh.metric = 'DB_FC_IO_RQ_SEC'
and  tmh.collectionMoment between to_date('09/02/2015 14:45:00', 'dd/mm/rrrr  hh24:mi:ss') 
and  to_date('09/02/2015 14:45:58', 'dd/mm/rrrr hh24:mi:ss')
group  by tmh.metric
,  tmh.metricUnit
,  to_char(tmh.collectionMoment, 'DD/MM/RRRR HH24:MI')
,  tmh.objectName
order  by tmh.metric
,  tmh.objectName
/

También puedes revisar el consumo de CPI en cada servidor de almacenamiento usando la siguiente consulta:

select  tmh.metric
,  ROUND(SUM(tmh.collectedValue_fixed), 0) as value
,  tmh.metricUnit
,  tmh.objectName
,  to_char(tmh.collectionMoment, 'DD/MM/RRRR HH24:MI') as moment
FROM  tabMetricHist_1hr tmh
WHERE  tmh.metric = 'CL_CPUT'
and  tmh.collectionMoment between to_date('09/02/2015 14:45:00', 'dd/mm/rrrr  hh24:mi:ss') 
and to_date('09/02/2015 14:45:58', 'dd/mm/rrrr hh24:mi:ss')
group  by tmh.metric
,  tmh.metricUnit
,  to_char(tmh.collectionMoment, 'DD/MM/RRRR HH24:MI')
,  tmh.objectName
order  by tmh.metric
,  tmh.objectName
/

Si estas usando IORM,  puedes hacer lo mismo para las categorías:

select  tmh.metric
,  ROUND(SUM(tmh.collectedValue_fixed), 0) as value
,  tmh.metricUnit
,  tmh.objectName
,  to_char(tmh.collectionMoment, 'DD/MM/RRRR HH24:MI') as moment
FROM  tabMetricHist_1hr tmh
WHERE  tmh.metric = 'CL_CPUT'
and  tmh.collectionMoment between to_date('09/02/2015 14:45:00', 'dd/mm/rrrr  hh24:mi:ss') 
and to_date('09/02/2015 14:45:58', 'dd/mm/rrrr hh24:mi:ss')
group  by tmh.metric
,  tmh.metricUnit
, to_char(tmh.collectionMoment,  'DD/MM/RRRR HH24:MI')
,  tmh.objectName
order  by tmh.metric
,  tmh.objectName
/

Conclusión

El script fue creado para permitirte leer los valores de las métricas de los servidores de almacenamiento directamente desde las instancias de los servidores de base de datos. Si quieres, puedes ajustar la ventana de tiempo para la recuperación de los datos para tu consulta y retornar los registro de los N días atrás, el máximo son 7 días. Los ejemplos y los pasos que te mostramos en este articulo fueron simples, pero tu puedes jugar con esas consultas, modificar los parámetros del script  y crear la tabla externa y la tabla física de la forma que tu quieras para poder cumplir con tus requerimientos. Puedes incluso hacer uso de la idea de este articulo para crear tus scripts personalizados y poder generar reportes desde Cloud Control 12c o desde cualquier otra herramienta que te permita realizar reportería. Puedes incluso configurar notificaciones para determinados valores de las métricas o solamente para las métricas que te interesen.  

Script 1: metric-hist-US.sh
Scritp 2: fixCumulativeMetric.sql

Fernando Simon es un Oracle DBA de la Corte de Justicia de Santa Catarina, Brasil. El ha sido un DBA por varios años habiendo trabajado con Oracle 9i hasta Oracle 12c, Fernando tiene experiencia en Oracle Exadata Database Machine desde su versión V2 hasta X4, y así también en soluciones de alta disponibilidad como Data Guard, Oracle RAC y replicaciones especiales. Él usualmente atiende eventos de Oracle en su país como un conferencista. Su blog es  http://www.fernandosimon.com/blog

Deiby Gómez ha sido distingiudo como Oracle ACE a los 23 años de edad, obtuvo el Oracle Certified Master 11g (OCM) a los 24 y se convirtió en Oracle ACE Director a los 25. Es el primer y único OCM 11g en Guatemala. Ha aparecido en "Oracle Magazine" y ha sido conferencista en muchos eventos de Oracle en varios países. Actualmente trabaja en Pythian. Twitter @hdeiby / blog www.oraclefromguatemala.com.gt

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.