Collecting CPU Measurement Facility

Collecting CPU Measurement Facility

Collecting CPU Measurement Facility

Desde el z10 el hardware de los zseries nos permite generar una serie de contadores y ejemplos que muestran el uso de PU´s de cada CP, nº de ciclos de reloj, caches, jerarquía del uso de memoria, etc. Esta nueva funcionalidad se conoce como el CPU MF. Para recoger esta información tenemos el Hardware Instrumentation Services o HIS. El HIS es una STC (necesita procesadores zIIP) que recoge los counters del CEC y genera los registros SMF tipo 113. La información extraída por el HIS es sólo de la LPAR donde se ejecuta.

Porqué  activarlo?

La información que genera el HIS sirve de apoyo para herramientas como el zPCR o el CP3000 que ayudan en las tareas de capacity planning. Nos muestra una imagen más fiable del RNI (Relative Nest Intensity) de nuestra carga de trabajo. Desde el z196 el LSPR agrupa las cargas en 3 categorías Low, Average, High basándose en el RNI.

Relative Nest Intensity

Relative Nest Intensity

El RNI es un ratio que ha inventado IBM para reflejar la distribución y la latencia de uso de caches compartidas y memoria.

Los contadores nos ayudan a comprobar el impacto del HIPERDISPACTH o el uso de CP por parte de programas de aplicación.

Counters y Samples

Para cada CPU lógica se generan los siguientes contadores:

*Basic. Contienen detalles de:

– Nº de ciclos ejecutados – nº de instrucciones ejecutadas – Uso de cahe L1 – La velocidad de los CP (expresada en ciclos por microsegundo)

*Problem-state. Son los mismos que los basic para cuando el CP están con algún problema.

Crypto Activity:  Actividad de los procesadores cryptográficos

¿Cómo se habilita?

his_como_trabaja

Para poder utilizar esta funcionalidad se necesita:

  • Habilitar en el SE de cada CEC en cada LPAR las pestañas de seguridad de cada contador. Versiguiente enlace.
  • Preparar el procedimiento HIS para la started task.
  • Usuario con acceso a Residente y SMF´s.
  • Usuario con segmento OMVS y HOME path designado.
  • ZFS montado en path designado (el tamaño dependera del tipo contadores seleccionados y tiempo de muestra).
  • Preparar SMFPRMxx para recoger los nuevos registros SMF.

¿Cómo sacas informes?

Por una parte tenemos los counters que se explotan a través de los registros SMF. Para estos datos será necesario explotarlos a través de una herramienta desarrollada propiamente o productos de proveedores externos. No he encontrado nada FREE que se pueda utilizar.

Y por otra parte tenemos los samples. Para ello utilizamos una aplicación USS para generar informes. Podéis guiarnos por el siguiente enlace. Esta herramienta genera informes en el USS con las siguientes extensiones:

Counter Set Data File (CNT). En este fichero genera todos los contadores que recoge el HIS. La información es necesario si quiere interpretarse los registros SMF 113. En cada contador muestra el tiempo de comienzo y finalización de cada intervalo por cada uno de los CPs. Es bastante difícil interpretar esta información.

START TIME: 2013/08/13 16:02:56 START TOD: CBCE4FB5BDE829A1
END TIME: 2013/08/13 16:12:56 END TOD: CBCE51F1F2A1CF20
COUNTER VALUES (HEXADECIMAL) FOR CPU 01 (CPU SPEED = 5208 CYCLES/MIC):
0- 3 000000006A45BE10 000000000CD9F699 000000000062353B 0000000020B7FD7F
4- 7 00000000004FB56F 000000004C440166 —————- —————-

Load Module Mapping File (MAP). Los ficheros MAP listan las direcciones virtuales de todos los programas cargados por todos los adress space. Estas direcciones pueden ser útiles para cruzar la información del SMP o para ver los límites del núcleo o la CSA. Para generar estos contadores el usuario de la started task HIS ha de tener acceso a todos los punteros donde residen los programas/objetos cargados en memoria. Aquellos espacio de direcciones que gestionan de forma autónoma los programas como CICS no aparecen aquí.

B BDY PRIVATE 00000000009FFFFF
B BDY CSA 00A0000000CA3FFF
B BDY CSAALLOC000C0CA803ECB4F8
B BDY CSACONVT0000000000000000
B BDY MLPA 00CA400000CDCFFF
B BDY FLPA 0000000000000000
B BDY PLPA 00CDD00000EBFFFF
B BDY SQA 00EC000000FD3FFF
B BDY SQAALLOC00045C6001671D30

Sampling report files (SMP). Estos ficheros se genera uno por CP lógico. Estan en formato ilegible. Poco usabilidad.

Más información en presentaciones del SHARE e IBM

@erobertoruiz

Pantalla verde?? interface viejuna??

He de reconocer que la primera vez que entre en una sala de ordenadores mainframe pensaba que estaba en la película de “WarGames”. Muchas pantallas verdes “tontas” conectadas con un cable coaxial a una 3*74.  Costaba mucho hasta que comenzabas a desenvolverte con soltura por el ISPF o el SDSF. Como apunta en su artículo Joe Winchester  “Simple is better” ahora aprender a manejarse con un z/OS es cada día más fácil. Hoy contamos con interfaces gráficas que ayudan a interacturar de forma más ágil.

Uno de los principales motores para la generación de este tipo de herramientas es acelerar el proceso de aprendizaje de los novatos. Es decir ayudar a cubrir la necesidad de renovar generaciones de mainframers. Según un estudio de 2012 de computeworld el 22% de los desarrolladores de COBOL tiene más de 55 años y el 50% se encuentra entre los 45 y los 55. Es un dato que da que pensar y así es visible en la encuesta realizada por Compuware a los CIOS de compañias que tienen un mainframe como base estratégica.

La consumerización existe tambien dentro de la TI. Las nuevas generaciones están familiarizadas con el uso de pantallas gráficas y manejarse a golpe de ratón.  Los recién licenciados no tienen interes por el mainframe. Prefieren desarrollar su carrera profesional en carrreras técnicas con tecnologías más comunes o más “nuevas”.  Estas generaciones demandan una interface gráfica de usuario (GUI) fácil, visual, sin necesidad de customización, etc que es a lo que están acostumbrados.

IBM y todos sus ISV están generando herramientas que cuidan mucho más la experiencia de usuario que hacen la vida más fácil a los mainframers y recuperan el interes de las nuevas generaciones. Con base en HTML, Java, Eclipse, etc se muestra una nueva cara de la relación entre mainframer y mainframe. Y es que las pantallas verdes pasaron a la historia.

Os dejo algunos ejemplo claros de este tipo de herramientas que están aquí para marcar el futuro del desarrollo, gestión y monitorización de aplicaciones mainframe.

RMF PM                 RMF spreadsheet             zPCR          z/OSMF            HCM                 RDz          CA Chorus      Mainview Explorer   Visual Explain

@erobertoruiz

High Performance FICON para z/OS

¿QUÉ ES ZHPF?

El zHPF es una funcionalidad que nos permite mejorar el rendimiento de nuestros canales FICON reduciendo entre un 10% y un 30% el uso de este tipo de canales. Activando el zHPF se mejora el número de I/O por segundo. Con el System z High performance FICON se eliminan los Command Control Word (CCW) por los Transport Control Word (TCW). Este cambio implica que en el mismo control block se procesen múltiples “information units” (IUs) reduciendo así el número de operaciones I/O.

Esta funcionalidad de los canales FICON mejora:

  • Capacidad adicional ante micro-cortes. Con zHPF se controla el estado de los I/O más eficientemente. Controla los estados de CU y Canal.
  • Uso de canal FICON reduciendo los tiempos de respuesta en picos de I/O
  • Accesos del tipo BSAM, QSAM y BPAM.
  • Mayor ratio Mb/segundo.
  • Mejora el uso del List Prefetch Optimizer del DB2 .

Existen numeroso documentos sobre zHPF generados por IBM y el SHARE donde podéis encontrar multitud de gráficos e información útil.

    ACTIVACIÓN DE ZHPF

Para la activación de esta nueva funcionalidad es necesario certificar que tanto los zEnterprise, las cabinas de discos y en el caso de que exista SAN los switch´s esten en el nivel apropiado de microcódigo. Después de certificar que tanto las cabinas de discos, la SAN y los zEnterprise se encuentran con el nivel de microcódigo necesario y aplicar mantenimiento a los sistemas z/OS (ver FIXCAT y PSP´s) se puede activar la funcionalidad de forma dinámica con el comando “SETIOS ZHPF=YES” o de forma estática en el miembro de PARMLIB IECIOSxx.

Para comprobar el impacto real se puede utilizar el monitor RMF. Con RMF spreadsheet reporter tenemos la posibilidad de extraer gráficas en los report predefinidos de DASD, IOQ y CHAN.

Se hace difícil comparar los datos ya que no todos los días existe la misma carga de acceso a disco. Normalmente se toma en cuenta la ventana BATCH que suele ser “más homogénea” en cuanto a acceso a disco.

Se debería tener en cuenta:

  •  Inventario de los recursos que disponemos.
  • Inventario de nuestras cargas de trabajo.
  • Recoger datos necesarios de SMF.
  • Separar de los datos recogidos información del HARDWARE (común para todas las LPAR´s) o SOFTWARE sólo para una LPAR. Este punto es importante porque no veremos las mejoras de esta funcionalidad hasta que todas las particiones se encuentren con ZHPF activo dentro de un mismo CEC.
  • Comprender la Jerarquía del Almacenamiento (Discos compartidos, Unidades de control físicas, Unidades de control lógicas, Volúmenes lógicos, Ficheros, etc).

Es necesario tener en cuenta que los informes de canal son comunes para todo el CPC. Los informes respecto a los discos y a IOQ son los únicos que podemos mirar a nivel de LPAR para observar el impacto de esta funcionalidad en cada nodo. Estos informes deberían de repetirse una vez todos los nodos en el sysplex se encuentren con zHPF activo.

Las métricas que pueden ayudar a ver la mejora son:

I/O Intensity: Es el producto de multiplicar el tiempo de respuesta por la tasa de actividad del canal. La unidad de medida se mide en milisegundos por segundos de solicitudes esperando el dispositivo.

Response Time (RT) : Tiempo de respuesta. Este dato se obtiene a través de la formula: RT= IOSQ + CONN + PEND + DISC

I/O Supervisor (IOSQ) = Encolamiento en la UCB de operaciones I/O. (Con el Hyperpav activo se elimina prácticamente la espera).

Connection time (CONN) = El tiempo en que el volumen lógico está conectado al canal. Con el ZHPF este dato se calcula de forma distinta (mirar documento ZSW03059USEN.pdf)

Disconnect time (DISC) = Es el tiempo de espera de desconexión del canal. Es decir cuando la operación de lectura o escritura utiliza la cache de la CU o escribe en disco y ya no depende del canal.

Pending time (PEND) = El tiempo de espera provocado por un retraso por Canal ocupado + CU ocupada + Disco ocupado. Con el ZHPF este dato se calcula de forma distinta (mirar documento ZSW03059USEN)

Service Time (ST) : Tiempo de servicio. Tiempo que el disco necesita para completar el I/O. Sería la suma del ST = CONN + DISC

RT/ST: Ratio de tiempo de respuesta por tiempo de servicio. Es una dato que nos muestra el grado de encolamiento que tiene una CU o Disco.

@erobertoruiz 

Migracion from ISC-3 to Infiniband

Migracion from ISC-3 to Infiniband

Este artículo me gustaría que sirviese aquellos departamentos de infraestructura que se ven o se veran obligados a migrar su actual arquitectura de coupling links de ISC-3 a Infiniband. Las nuevos zEnterprise no permiten utilizar ISC-3 por lo que es menester migrar.

 Introducción a la tecnología INFINIBAND en Mainframe

La tecnología Infiniband es una especificación estándar realizada por InfiniBand Trade Association (sus siglas son IBTA y está formada por empresas como Compaq, IBM y Hewlett-Packard) que define la arquitectura de entrada-salida para interconectar servidores, almacenamiento, etc. Esta arquitectura permite interconectar máquinas punto a punto con un ancho de banda de hasta 120Gbps. Utiliza el protocolo Remote Direct Memory Access (RDMA) que permite optimizar la transferencias de datos. Nos ofrece nuevas posibilidades de:

  • ·         Mejor rendimiento. Aumentas el ancho de banda.
  • ·         Reducir la complejidad. Puedes reducir el número de cableados y enlaces.
  • ·         Eficiencia en las interconexiones. Mayor escalabilidad.
  • ·         Fiabilidad y estabilidad. Facilita la virtualización y facilita la fiabilidad y estabilidad de las conexiones.

A nivel físico cada enlace de Infiniband está basado en dos pelos de fibra de 2.5 Gbps bidireccionales para una conexión óptica o 4 hilos de cobre a 2.5 Gbps para una conexión electrónica. Las fibras necesarias son Mono-Modo . Cada enlace puede soportar varios servicios de transporte . Cada enlace es agrupado dependiendo del tipo de implementación (1x, 4x, 8x o 12x). Dependiendo del nivel físico

  • ·         Single Data Rate (SDR), provee 2.5 Gbps por enlace.
  • ·         Double Data Rate (DDR), provee  5.0 Gbps por enlace.
  • ·         Quadruple Data Rate (QDR), provee 10.0 Gbps por enlace.

En la configuración de entrada/salida del z196-z114/zEC12-zBC12 manejaremos los siguientes conceptos: 

 PSIFB             à Parallel Sysplex Infiniband

HCA                à Host communication Adapter

AID                 à Adapter ID

FANOUT        à Tarjeta Infiniband

Hay varios tipo de tarjetas Infiniband HCA2-O (2 puertos) y HCA3-O (4 puertos). Podéis encontrar más detalles en el redbook del z196/zEC12. Para instalaciones que tengan varios centros las conexiones se crearan en el modo LR 1X.

hca2lr1x

En la configuración del IODF la definición de estos canales no se habla de PCHID si no de HCA/AID. Para la definición es necesario saber donde se encuentra el Faonut de cada tarjeta. Para ello es necesario consultar el support element o preguntar a nuestro soporte de HARDWARE. Dicha información se pude ver tambien si teneis reports de algún mapping tool.

Cada puerto soporta hasta 8 CHIPDS lógicos sobre el mismo enlace físico. Sin embargo IBM recomienda que no se definan más de 4 por puerto.

El uso de Infiniband nos permitiria reducir el consumo de CP´s de uso general y ICF´s.

Los procesarores son utilizados para:

  • ·         Encontrar un canal disponible.
  • ·         Encontrar buffer link disponible
  • ·         Enviar la solicitud del subsitema de canales a la CF
  • ·         Procesar la peticion en la CF
  • ·         Enviar la petición de vuelta al z/OS
  • ·         Recibir la petición de la CF y procesarla en el z/OS

Reduciriamos aprox un 20% en el uso de procesador para las operaciones de conexión z/os to coupling facility y viceversa.

Como muestran las siguientes figuras extraídas de estudios de IBM reduciriamos las unidades de servicio (mayor número de operaciones de síncrona vs asíncronas, menor uso de buffers por canales ocupados, etc).

zos CPU utilizationCF CPU utilization

 Synch Responde Times

Cuadro comparativa ISC-3/Infiniband

Interconnected channel-3 Infiniband HCA2-o Long reach 1x
Ancho de banda 2Gb/segundo 5Gb/segundo
Distancia permitida entre enlaces 100 Km 175 Km
Cableado 9 μm single mode fiber optic 9 μm single mode fiber optic
CHPID´s por puerto físico CHPID/puerto 16CHPID/puerto
Impacto de la distancia entre enlaces 10 microsegundos por Km en unidades de servicio 10 microsegundos por Km en unidades de servicio
latencia Depende de la distancia, tipo de carga, cableado y DWDM Depende de la distancia, tipo de carga, cableado y DWDM
Requisitos microcódigo HW Driver 86 Driver 93 Bundle 18

Requisitos necesarios para utilizar INFINIBAND.

Para utilizar esta tecnología es necesario cumplir con una serie de requisitos.

Requerimientos Hardware. Es necesario tener Driver 93 y bundle superior al 13.

Requerimientos Software. Consultar en las FIXCAT:

  • IBM.Device.Server.zXXX-28xx
  • IBM.Device.Server.zXXX-28xx.ParallelSysplexInfiniBandCoupling
  • IBM.Device.Server.zXXX-28xx.ServerTimeProtocol

Requerimientos DWDM. Consultar lista de proveedores certificados

Consideraciones con el STP. Después de la activación del cambio será necesario comprobar que el STP ha asumido los nuevos canales desde la pantalla de “Systems (Sysplex) Time” en el HMC.

Aspectos a tener en cuenta:

Un canal Infiniband sólo puede conectarse a otro canal Infiniband.

Cuando se construye el IODF el cableado ha de encontrarse fisicamente conectado.

Toda la información se ha extraído de IBM y del SHARE. Podéis encontrar más información en: