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 

El mainframe está preparado para la avalancha

El mainframe está preparado para la avalancha 

La avalancha esta aquí y arrasará con aquellos que no estén preparados. El mainframe sigue joven y a sus 50 años no para de mejorar. En la situación actual confluyen varias tendencias que están cambiándolo todo. Es por ello que el mainframe sigue innovando continuamente para dar soluciones a estos nuevos retos. Como apunta Alan Radding en su blog “Dancing dinosour”  el mainframe es capaz de asumir la avalancha que da lugar la movilidad, el cloud computing, el social media o el Big Data. El mainframe sigue apalancando a negocio con nuevas soluciones como es el acelerador IDAA  . IBM DB2 Analytics Accelerator for z/OS permite utilizar la potencia del appliance Netezza

Netezza es una compañia que compro IBM en septiembre de 2010 para posicionarse en el mercado de la analítica de datos. Competencia de Teradata, Exadata, etc se comercializa con el nombre de IBM Pure Data. Esta familia de soluciones cubre un amplio abanico de soluciones para analítica. 

¿Qué es IBM PureData/Netezza?

Se trata de un dispositivo Ad-on (caja negra SW+HW) que permite optimizar las querys pesadas de BBDD DB2 tanto para OLTP como OLAP. Sus características principales son:

  • Reducción de MIPS/CPU y coste por licencias de software (WLC, MLC, etc) en el z/OS.
  • Consolidar la carga crítica en el z/OS (aprovecharnos de la resiliencia, robustez, seguridad, disponibilidad, escalabilidad, etc del mainframe).
  • Accelerar la generación de información/conocimiento a partir de datos. Habilita realizar un uso de los datos más eficiente posibilitando tener el conocimiento en muchísimo menos tiempo.

 ¿Cómo funciona?

El Netezza que posee distintos modelos conforme a las necesidades del cliente. El más pequeño de la familia el módelo es el 1000.1 tiene las siguientes carácterísticas:

  • S-Blades                                 3
  • Cabinets                               1/4
  • Processing Units                 24
  • Capacidad (Tb)                     8
  • Capacidad Efectiva (Tb)    32

Su sistema operativo es un Red Hat Linux Advanced Server y soporta distintos estándares de SQL así como distintos tipos de analítica (In-database, Hadoop, R, Matrix, etc)

IBM Netezza 1000 utiliza Field Programmable Gate Arrays (o FPGAs) que se han programado específicamente para gestionar grandes volúmenes de datos con una gran eficiencia. Estos FPGAs filtran datos irrelevantes tan pronto salen del disco. Esto elimina cuellos de botella de E/S y hace que los componentes situados a continuación del proceso, tales como la CPU, la memoria y la red, no tengan que procesar datos innecesarios, creando un efecto turbo considerable en el rendimiento del sistema.

La complejidad del análisis se lleva a cabo en potentes CPUs de varios núcleos, en los que se ejecutan primitivas de base de datos y análisis complejos en la corriente de datos filtrados. Las tareas de análisis se ejecutan como procesos independientes que operan en las corrientes de datos en cada S-Blade. La plataforma IBM Netezza Analytics se encarga de la potencia de todos  los núcleos computacionales del dispositivo para ofrecer un rendimiento considerable y escalabilidad para análisis avanzados, presentando una vista abstracta para simplificar su despliegue.

Utiliza tecnologías como :

  •  In-Memory. Cada blade posee 674Gb de RAM de los cuales 352Gb puede utilizarse para almacenar datos comprimidos que sería 1Tb de datos en DB2.
  • MPP.  Massive Parallelism procesing. Permite procesar en paralelo las querys a modo que se realiza un preprocesamiento a través de las FPGAS y posteriormente se unen los resultados de cada tarjeta y se procesa en los SMP-HOST.
  • Compresión extrema. Permite comprimir los datos en ratio 4/1.
  • En el interior de Netezza utiliza BBDD por columna y filas de aquí que en muchos casos sea mejor no definir las BBDD en DB2 con índices.

Existen muchas variedades de licenciamento, se vende como software y se paga por espacio contratado.

¿Infraestructura necesaria para utilizar Netezza desde un z/OS?

La conectividad entre el zEnterprise y el Netezza se realiza a través de tarjetas OSA-Express de 10Gb definidas en el IODF como OSD o OSX (depende si tenemos zBX o no).  Dichas tarjetas OSA´s son utilizadas por el VTAM y el TCPIP como vehículo de acceso desde IDAA a Netezza y Viceversa.  La conexión desde el z/OS al Netezza se realiza a través de un nodo TRLE de VTAM y una VIPA del TCPIP.

 IBM DB2 Analytics Accelerator for z/OS

IDAA es un software que se instala en el z/OS y que redirige las querys “pesadas” al Netezza. La versión más reciente es la versión 4.1 en la que existen mejoras considerables con respecto a la versión anterior (leer siguiente enlace) Lo hace a través de un algoritmo que decide cuando una query es pesada. Este producto se instala junto la Infosphere Change Data Captura Para la administración del producto se utiliza una herramienta bajo SO Windows llamada IBM DB2 Analytics Accelerator Studio. Desde esta herramienta gráfica se seleccionan las BBDD que quieren que estén en NETEZZA. Se puede utilizar el IDAA para varios subsistemas DB2 contra el mismo Netezza.  Este software necesita:

  • Instalación con SMP/E
  • Modificaciones en la Zparm del DB2 para indicar que tipo de querys van a ser aceleradas.
  • Generar una serie de tablas en el catalogo del DB2 y procedimiento almacenados
  • Procedimiento almacenados
  • Application Enviroment en WLM que siguen las reglas de clasificación de cargas DDF
  • Librerias en APF
  • Java versión 6
  • Path en los USS .

Para que IDAA puede direccionar las querys pesadas al Netezza se necesita que previamente se hayan copiado las tablas al NETEZZA (copia del catálogo DB2 las tablas seleccionadas). El proceso de carga se puede realizar desde IBM DB2 Analytics Accelerator Studio o a través de un batch que invoka una REXX que llama a un procedimiento almacenado.  Todas las acciones que se realizan desde la herramienta gráfica invocan a un application enviroment que posteriormente llama a un procedimiento almacenado.

Este proceso de carga sigue los siguientes pasos (es el producto Infosphere Change Data Capture quien se encarga):

  •  Descarga de las tablas a ficheros temporales (USS Pipes).
  • Transmisión de los USS Pipes a Netezza.

 ¿Qué problema solventa y que posibilidades permite?

Gracias a este acelerador y una plataforma de integración apropiada se pueden explotar mucho más eficientemente nuestros almacenes tradicionales de datos. Se ofrecen oportunidades cómo:

  • Predicción del fraude en tiempo real. Se pueden realizar analísis predictivos que permitan saber resultados futuros y evaluar en detalle situaciones o patrones que inquen un posible fraude.
  • Predecir lo que quieren los clientes, conocer en tiempo real las campañas de promoción o lanzamientos de nuevos productos o servicios.
  • Reinventar los procesos de negocio. Optimizando las decisiones convirtiendo la visión de los datos de ayer sobre observaciones sobre datos en tiempo real.
  • Impacto directo en TCO. Un ROI inferior en algunos casos a los 4 meses.
  • Reducción en algunos casos de hasta en 1000 veces el tiempo de respuesta de consultas a DB2

@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: