Libro Blanco System z

Libro Blanco System z
Tabla de contenido
1
2
Introducción
5
1.1
1.2
5
5
Características de la plataforma
2.1
2.2
2.3
2.4
2.5
2.6
2.7
3
Objetivo del documento
Organización del documento
6
Capacidad
6
2.1.1 Qué entendemos por capacidad
6
2.1.2 Elementos que integran la capacidad de un sistema
6
2.1.3 ¿Pocos o muchos servidores?
7
2.1.4 Cargas mixtas
7
2.1.5 Gestión de Sistemas basado en SLAs
8
Virtualización de recursos
8
2.2.1 Virtualización de CP
9
2.2.2 Virtualización de memoria
9
2.2.3 Virtualización de E/S
9
2.2.4 Virtualización de comunicaciones.
9
2.2.5 Donde IBM System z triunfa sobre la virtualización de la arquitectura
x86.
10
2.2.6 IBM System z puede tener mucho sentido para determinadas
aplicaciones e iniciativas
11
Escalabilidad
12
2.3.1 Introducción (conceptos de vertical, horizontal y aprovisionamiento)
12
2.3.2 Escalabilidad del hardware
13
2.3.3 Escalabilidad de los S/O. z/OS z/VM y Linux for System z
14
2.3.4 Sysplex Paralelo
14
2.3.5 Capacidad bajo demanda (lo nuevo de z/OS de aprovisionamiento)
15
Integridad y Seguridad
15
2.4.1 Integridad
15
2.4.2 Seguridad
17
Rendimiento
19
Disponibilidad
20
2.6.1 Construido para los negocios.
20
2.6.2 Una solución para la operación continúa de los negocios.
21
2.6.3 Disponibilidad y fiabilidad de primera clase
21
2.6.4 Fortalezas del corazón del hardware.
22
2.6.5 Mas allá del hardware
23
Gestión de Sistemas
25
2.7.1 Revisión de la administración de sistemas.
26
2.7.2 El valor de la administración de sistemas en el z/OS
26
2.7.3 Iniciativa del ordenador autónomo de IBM
27
2.7.4 Tecnologías auto-configuradoras.
28
2.7.5 Tecnologías auto-reparadoras
29
2.7.6 Tecnologías auto-optimizadoras
29
2.7.7 Tecnologías auto-protectoras.
29
2.7.8 Administración de los sistemas End-to-end
29
Arquitectura System z. Plataforma HW
31
3.1
31
31
32
34
36
36
3.2
Conceptos de la arquitectura System z
3.1.1 Multiprogramación/Multiproceso/Multithreading
3.1.2 Mecanismo de interrupciones
3.1.3 Virtualización
3.1.4 Otras características importantes del HW
Componentes y sus características
IBM Corporation
21/02/2011
2 de 131
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
3.2.7
3.2.8
3.2.9
3.2.10
4
36
37
38
39
41
41
41
41
42
43
Arquitectura System z. Plataforma SW- SW Base
44
4.1
44
45
46
48
48
49
50
51
52
52
52
53
53
54
54
54
56
56
56
57
57
59
60
4.2
4.3
4.4
4.5
5
Z10
Procesadores
Memoria
E/S
Time-of-Day clock
CP Assist for Cryptographic
HiperSockets
Hardware Management Console (HMC)
Detalles de virtualización del HW
Hiperdispatch
IBM z/OS y componentes
4.1.1 Gestión de la Memoria
4.1.2 Gestión y reparto del Procesador- Workload Manager (WLM) .
4.1.3 Resource Recovery Services (RRS).
4.1.4 Gestión de los datos DFP(Data Facility Program)
4.1.5 Gestión del Almacenamiento
4.1.6 Gestión de los bloqueos -Global resource serialization (GRS)
Entorno de programación/ejecución
4.2.1 Soporte de Runtime- Language environment
4.2.2 ´Compiladores de los lenguajes de programación tradicionales
4.2.3 Soporte de Java
4.2.4 Lenguajes de reciente incorporación
4.2.5 Herramientas de desarrollo de SW
4.2.6 XML Services
4.2.7 UNIX System Services
4.2.8 Security Server
Técnicas de clustering. Sysplex Paralelo
4.3.1 Clustering básico
4.3.2 ‘Anillo GRS’
4.3.3 Sysplex Paralelo (Resource sharing y Datasharing)
4.3.4 Coupling Facility
z/VM
Linux en System z
Arquitectura System z. Plataforma SW-Middleware Transaccional
61
5.1
62
63
64
64
65
65
66
66
67
68
68
69
69
70
71
73
75
75
76
78
80
81
5.2
5.3
5.4
CICS
5.1.1 El CICS y el z/OS
5.1.2 Programas, transacciones y tareas CICS
5.1.3 Programación conversacional y pseudo-conversacional
5.1.4 Comandos CICS
Servicios CICS para los programas de aplicación
5.2.1 Objetos de datos CICS
5.2.2 Acceso a datos externos
5.2.3 Topología CICS
5.2.4 Intercomunicación CICS a CICS
5.2.5 Conectividad con sistemas no-CICS
5.2.6 Configuración CICS
5.2.7 Seguridad
5.2.8 Herramientas para depuración y de determinación de problemas
IMS
5.3.1 IMS Database Manager (IMS DM)
5.3.2 IMS Transaction Manager
5.3.3 Servicios de sistema IMS
5.3.4 Estructura de los subsistemas IMS
WAS
5.4.1 Nodo de servidor base de aplicaciones:
5.4.2 Network Deployment Manager:
IBM Corporation
21/02/2011
3 de 131
5.5
5.6
5.7
6
MQ
5.5.1 Tipos de mensajes
5.5.2 Gestor de Colas
5.5.3 Tipos de colas de mensajes
5.5.4 ¿Qué es un canal?
5.5.5 ¿Cómo queda asegurada la integridad transaccional?
5.5.6 Un ejemplo de mensajería y encolamiento
5.5.7 Interfaz con CICS, IMS, Batch, o TSO/E
Middleware Bases de Datos
5.6.1 DB2
SW de gestión
5.7.1 Gestión de almacenamiento
5.7.2 Gestión de la operación (Tivoli SA y Netview)
5.7.3 Gestión del Batch
5.7.4 Monitorización y rendimiento
86
88
89
89
90
90
92
93
93
93
101
101
101
103
104
Integración en los modelos IT más usados en la actualidad
109
6.1
109
109
109
110
112
117
6.2
SOA
6.1.1 Introducción
6.1.2 Estándares en SOA
6.1.3 Construyendo las TI con nuevos parámetros
6.1.4 Mejores prácticas SOA
Proceso en nube (Cloud computing).
La evolución del IBM System z: zEnterprise
Modernización empresarial en zEnterprise
Transformar sus activos de TI para proteger sus inversiones
Modernice su empresa para maximizar la agilidad
122
122
124
124
Consolidación de servidores
126
Introducción
Tipos de Consolidación.
Consolidación en System z
126
127
127
Bibliografía
130
7
IBM Corporation
21/02/2011
4 de 131
1 Introducción
1.1 Objetivo del documento
El objetivo de este documento es describir la plataforma System z en sus componentes
más importantes.
Intentamos establecer las características de la plataforma en relación con el tipo de
necesidades a las que va dirigida, así como documentar la tecnología que soporta
dichas características.
El mundo System z avanza y por lo tanto este documento quedará obsoleto en cuanto
se anuncie la siguiente máquina.
No obstante el paradigma System z se ha mantenido a lo largo de los más de 40 años
de existencia de la plataforma y esperamos que se mantenga muchos más.
Si bien los detalles pueden cambiar, el contenido de este libro es general de la
plataforma.
1.2 Organización del documento
Hemos dividido el documento en tres partes:
1. Una primera (Capítulo 2) que habla de las características que son
importante en una plataforma. Las características que todas las plataformas
tienen pero cada una en su medida.
Esta diferente manera de ser escalable, o los distintos límites de capacidad,
o lo que en cada plataforma se define como alta disponibilidad, es lo que
hemos querido reflejar en este primer capítulo.
2. Hay una segunda parte compuesta por los capítulos 3, 4 y 5 que intenta dar
una descripción técnica tanto del HW como el SW más usado en el
Mainframe.
Esta parte complementa la primera, dotándola de mas profundidad.
3. Y, por último hay un capitulo dedicado al papel e System z en los
paradigmas de negocio que están apareciendo a fecha de 2010.
Estos paradigmas están basados en características de la infraestructura que para
System z son características de nacimiento, como por ejemplo la seguridad, la
integridad, la virtualización, etc.…
Este capítulo pretende solo dar unas pinceladas sobre este papel.
IBM Corporation
21/02/2011
5 de 131
2 Características de la plataforma
2.1 Capacidad
2.1.1 Qué entendemos por capacidad
Mirando en el diccionario de la Real Academia de la Lengua, encontramos las
siguientes definiciones:
1. Propiedad de una cosa de contener otras dentro de ciertos límites.
2. Oportunidad, lugar o medio para ejecutar algo.
En el Webster encontramos como definición nº 5:
5. La facilidad o poder para producir, ejecutar o utilizar.
Como vemos se trata de un potencial. Algo que puede llegar a realizarse o no, pero que
está a nuestra disposición. Una vez dicho esto, me gustaría definir la capacidad con un
ejemplo de la vida cotidiana: Un litro de leche. ¿Qué es un litro de leche? La leche que
cabe en una jarra de un litro. Pensemos en el ordenador como la jarra. Ahora bien, si la
jarra la llenamos de agua, vino o leche, los resultados de bebernos dicha jarra no son
los mismos, y ya no digamos si la jarra la llenamos de ambrosía…
La capacidad de los ordenadores se suele medir por el número de instrucciones que
pueden realizar en determinado tiempo. Funciones o peticiones tales como abrir un
fichero o leer un registro, dependiendo de en qué lenguaje de programación estén
escritas, si es un lenguaje compilado o interpretado, de lo buen o mal programador que
seas, del método de acceso utilizado, pueden requerir 10 ó 300 ó 50.000 instrucciones.
Una de las características fundamentales del sistema z es su habilidad para utilizar el
100% de su capacidad sin merma en su rendimiento.
El System z dispone de elaboradas utilidades en cuanto a rendimiento, que facilitan la
labor a la hora de conocer los consumos de cada recurso.
El CMG (Computer Measurement Group), fundado en 1974, es una organización sin
ánimo de lucro de profesionales de la informática dedicada a compartir información y
normas de buen uso para asegurar la eficacia y escalabilidad de los sistemas de IT, a
través de la medición, el análisis cuantitativo y la predicción. Dispone de una base de
datos de artículos en la siguiente página web: http://www.cmg.org/
2.1.2 Elementos que integran la capacidad de un sistema
Para poder conseguir ese potencial debemos basarnos en los elementos que
configuran dicho sistema y las interrelaciones entre ellos.
Como elementos fundamentales tenemos: los procesadores, su arquitectura, el juego
de instrucciones que dicho procesador es capaz de ejecutar, los elementos de
entrada/salida para acceder a los datos, la memoria, los tipos de caché, el
direccionamiento y la virtualización. (Esto se verá con más detalle en el capítulo 3º)
Como interrelaciones el elemento más importante del que disponemos es el sistema
operativo que permite acceder a los recursos anteriores sin las complejidades de la
programación de chips.
IBM Corporation
21/02/2011
6 de 131
Esto en cuanto a elementos que operan a nivel de servidor. Si necesitamos correr
varios servidores en una sola máquina tenemos que tener en cuenta otros elementos
que influirán a la hora de la capacidad de la máquina, como por ejemplo la compartición
de recursos o su imposibilidad, y el nivel de dicha compartición en el caso de que sea
posible. Esto también exige la seguridad de que compartimos lo que necesitamos y al
nivel requerido, sin intrusiones de un servidor en otro o machaque de áreas privativas.
Más adelante hablaremos de cada una de estas áreas con más detalle. Sólo señalar
aquí que el sistema z dispone de las más altas certificaciones de seguridad.
2.1.3
¿Pocos o muchos servidores?
La evolución del paradigma de sistemas distribuidos “una aplicación, un servidor”, ha
llevado al crecimiento desmesurado del número de servidores en una instalación. Baste
un ejemplo: Un centro con sólo dos aplicaciones corriendo contra una base de datos.
Esto no parece muy complicado: 4 servidores para los servidores de aplicación (dos por
aplicación por redundancia), 2 para la base de datos (activo/activo o activo/pasivo), total
6 sistemas. Pero hay que contar con 3 más para el desarrollo y otros 3 para QoS. Si
además necesitamos garantizar el servicio ante un desastre necesitamos 6 más para
producción y otros 3 para desarrollo, En total ya tenemos 21 servidores/máquinas que
manejar. Y esto sólo para dos aplicaciones y sin tener en cuenta el posible crecimiento
de la aplicación, que, en general, se solventa con la adición de nuevos servidores.
Cuántos más servidores haya que administrar más complicada es la tarea, más
problemas a resolver con más puntos de fallo, más tiempo perdido en tareas puramente
administrativas (como el cambio de sistemas operativos o su mantenimiento) y más
difíciles de controlar la seguridad y las comunicaciones.
El Mainframe tiene un paradigma diferente: “todas las aplicaciones compartiendo un
sistema”. A simple vista esto parece más sencillo de manejar, y en realidad lo es si el
sistema es capaz de priorizar las tareas importantes y serializar las peticiones a los
recursos para evitar que tareas intrascendentes monopolicen la máquina y para
garantizar la integridad de las operaciones.
2.1.3.1
Muchos servidores
Como resumen, muchos servidores dificultan las tareas administrativas, aumentan el
tiempo de la resolución de problemas (sobre todo si los sistemas pertenecen a distintas
organizaciones), complican los procedimientos de pruebas y de recuperación ante un
desastre y generan conflictos de propiedad entre departamentos.
Y además, gastan más energía (hay entidades que han tenido problemas de suministro
e incluso en determinados países se está publicando legislación para impedir que se
consuma más allá de un máximo de energía) y utilizan más espacio, cableado y
conectores.
2.1.3.2
Pocos servidores.
Como contrapartida, cuantos menos servidores, se utiliza menos energía, menos
espacio, se tarda menos tiempo en la resolución de problemas y la administración de
los sistemas es más sencilla, es decir, se mejoran todos los aspectos anteriores
2.1.4
Cargas mixtas
El concepto de carga mixta va emparejado con el paradigma del Mainframe. Es el tipo
de trabajo que se realiza cuando todo tipo de aplicaciones corren en un solo servidor,
así tenemos transacciones on-line que se generan a través de middleware del tipo
CICS/WAS/IMS, manejo de datos ya sea a través de ficheros, secuenciales o de
IBM Corporation
21/02/2011
7 de 131
acceso directo, o de bases de datos, comunicaciones con los distintos tipos de
terminales, tareas en lotes, gestión de seguridad, etc.
El sistema z, gracias a su arquitectura y características únicas, es capaz de combinar
un gran número de cargas priorizando las tareas importantes, asignando los recursos
necesarios y ofreciendo seguridad a medida, compartiendo al mismo tiempo todos los
recursos del sistema de una forma segura.
Un factor importante en este punto es el WLM, (Work Load Manager), elemento
integrado en el sistema operativo, que permite definir las prioridades del sistema a
través de políticas, con un lenguaje igual al utilizado en los compromisos de niveles de
servicio. Dicho componente, además de priorizar las tareas, asigna los recursos
necesarios para conseguir el rendimiento deseado según los SLA’s y balancea la carga
a lo largo de un Sysplex para conseguir los máximos beneficios de capacidad y
rendimiento que ofrece el System z.
2.1.5 Gestión de Sistemas basado en SLAs
En una instalación se manejan muchos tipos de trabajo: producción, desarrollo, test,
administración, pruebas de calidad, etc.
También se dispone de muchos tipos de aplicaciones, algunas de las cuales son
prioritarias y requieren inmediatez en su ejecución, mientras que otras pueden esperar
incluso minutos, sin que por ello pierdan efectividad.
Generalmente, este tipo de conocimiento escapa a la gente que administra los
sistemas, ya que éste pertenece al ámbito del negocio. Por eso se establecen
compromisos de SLA’s (Service Level Agreement). En este tipo de acuerdos se
establecen niveles de servicio tales como tiempo de respuesta, disponibilidad de la
aplicación, requerimientos de recuperación, etc.
Este tipo de acuerdos también sirve para una posible facturación interna de los
servicios prestados.
El sistema z permite la definición de la importancia de las tareas con políticas basadas
directamente en los SLA’s. Estas políticas se actualizan on-line,
2.2 Virtualización de recursos
La virtualización hace referencia a la técnica de ocultar las características físicas de los
recursos informáticos a los usuarios de dichos recursos.
El hecho es que la virtualización no es de ninguna manera un concepto nuevo o un
nuevo invento de la tecnología, aunque ahora se aplique también a la informática
distribuida, ya que la plataforma System z de IBM la ha soportado durante mucho
tiempo y la ha ido perfeccionado a lo largo de décadas. No olvidemos que MVS, el
nombre antiguo del z/OS, significa ‘Multiple Virtual System’ y VM, el nombre que desde
los 70 ha llevado el nuevo z/VM significa ‘Virtual Machine’.
Algunos expertos de la industria sostienen que la virtualización de los servidores está
convirtiendo el centro de datos a una arquitectura que “imita” al Mainframe. Esto es
relativamente cierto aunque un poco simplista ya que esta teoría ignora el hecho de que
la arquitectura x86 tiene unos límites de escalabilidad, fiabilidad y rendimiento que
constituyen la quintaesencia de la plataforma System z de IBM. Y la simple
virtualización no incorpora la gestión integrada en la plataforma System z.
IBM Corporation
21/02/2011
8 de 131
2.2.1 Virtualización de CP
Processor Resource/Systems Manager™ (PR/SM™) es un hipervisor integrado en
todos los System z que correlaciona los recursos físicos de la máquina con recursos
virtuales. Esto permite que muchas particiones lógicas puedan compartir dichos
recursos físicos.
Los CP’s quedan integrados en un pool y a cada partición se le asocia un número lógico
de ellos. El PR/SM proporciona los procesadores físicos y en caso de necesitar más
CP’s de los que haya físicamente disponibles, decide dar los recursos de acuerdo al
peso otorgado a cada partición.
En el z10, para evitar pérdidas de rendimiento debidas a los movimientos de cache
entre los procesadores físicos, surge el hiperdispatch.
2.2.2 Virtualización de memoria
La memoria no se puede ser compartir entre particiones. Cosa lógica porque ahí es
donde están los datos de cada aplicación. Sin embargo en el sistema z existen varias
opciones que permiten una mejor utilización de la memoria.
En primer lugar se pueden pasar trozos de memoria de unas particiones a otras por
medio de comandos. Así nos aseguramos que se han salvado los datos pertinentes y
que éstos no están en uso por alguna aplicación.
En segundo lugar, dentro de cada partición, la memoria se virtualiza dependiendo del
sistema operativo. Tanto z/OS como z/VM son capaces de virtualizar la memoria hasta
conseguir un alto rendimiento en su utilización.
El z/OS dispone de tablas de direccionamiento de memoria que permiten que cada
espacio de direcciones pueda funcionar como si dispusiera de toda la memoria, no sólo
la existente realmente, sino toda la que pueda direccionar. Para ello dispone de ficheros
de paginación, en los que se puede respaldar memoria que no esté en uso, permitiendo
así que dicha memoria pueda ser usada por otra aplicación.
El z/VM se encarga de distribuir la memoria entre sus huéspedes. Puede obtener un
over-commit de hasta dos veces su capacidad.
2.2.3 Virtualización de E/S
El sistema z es el único en el mercado que dispone de un ‘subsistema de canales’
encargado de realizar la E/S para todas las particiones, convirtiéndose así en el
paradigma de la virtualización. Este subsistema de canales distribuye su inteligencia
entre un procesador especializado (SAP) y los canales, que también disponen de
procesadores.
Por otro lado también dispone del EMIF, que permite compartir canales entre las
distintas particiones, sin necesidad de disponer de cableados adicionales para cada
sistema.
2.2.4 Virtualización de comunicaciones.
Puede compartir tarjetas de comunicación IP entre varias particiones.
IBM Corporation
21/02/2011
9 de 131
Dispone de un mecanismo de comunicación entre particiones denominado
HiperSockets que permite comunicaciones IP entre particiones sin necesidad de
cableado, a velocidad de memoria.
Dentro del z/VM dispone de mecanismos tales como la ‘guest LAN”, que es una red
LAN virtualizada, y el virtual switch.
2.2.5 Donde IBM System z triunfa sobre la virtualización de la arquitectura
x86.
La llegada de la virtualización de los servidores x86 está proporcionando grandes
avances dentro de los departamentos de IT, pero aún tiene defectos y fallos cuando lo
que las organizaciones buscan es ejecutar modernas aplicaciones de empresa.
La tecnología de virtualización de servidor es realmente buena al hacer un uso más
eficiente del hardware con la ventaja añadida de una mejora en la recuperación ante un
desastre.
Por otra parte, IBM System z se ha construido desde el principio para ejecutar
aplicaciones empresariales críticas que demandan una plataforma de hardware flexible,
escalable y de una alta disponibilidad.
Mientras que la virtualización del x86 puede gestionar bien tareas sencillas, la
virtualización del Mainframe se aprovecha de más de 30 años de innovaciones tales
como:
Un hardware tolerante al fallo que excede en mucho cualquier cosa que la virtualización
x86 pueda ofrecer. El System z de IBM se ha diseñado para tolerar fallos de hardware
sin comprometer la disponibilidad o el rendimiento del sistema.
Capacidad bajo demanda (CoD), donde las necesidades de capacidad de proceso y de
memoria se acceden bajo petición. El System z de IBM se entrega con capacidad
integrada que se puede activar cuando las cargas excedan los requerimientos de la
capacidad original.
Virtualización de E/S para ofrecer un rendimiento predecible que escala fácilmente
cuando la aplicación lo requiera. Los cuellos de botella en la E/S son uno de los
obstáculos fundamentales en las soluciones de virtualización del x86.
Seguridad e integridad, reforzadas ambas dentro de la arquitectura del System z de
IBM y probadas fehacientemente en los más exigentes entornos de aplicación. Mientras
que las plataformas de virtualización x86 son relativamente nuevas y aún tienen que
demostrar su valor en entornos que requieran las más altas medidas de seguridad.
Elegir la solución de virtualización no es tan blanco o negro como pueda parecer.
Las ventajas básicas de la virtualización incluyen la consolidación y la mejora en la
utilización de recursos, beneficios que son bienvenidos en todas las organizaciones.
Se necesitan otras consideraciones para comprender las aplicaciones y el impacto
positivo que la virtualización tendrá a varios niveles en los tier de infraestructura
subyacente.
IBM Corporation
21/02/2011
10 de 131
2.2.6 IBM System z puede tener mucho sentido para determinadas
aplicaciones e iniciativas
La tecnología Mainframe de IBM, tal vez injustamente, ha llevado el sambenito de
unidades de proceso caras (MIPS) y un historial de excelente rendimiento para cargas
específicas en sectores específicos.
Por ejemplo, si desea implementar SOA y WebSphere para optimizar el beneficio del
proveedor y para investigar la elegibilidad de proceso en el sector sanitario, el IBM
System z es el camino a seguir.
Sin embargo, estos conceptos están cambiando a la vez que grandes entornos Linux se
consolidan en Mainframe con un TCO mejorado en comparación con el despliegue del
mismo entorno en arquitectura x86.
La arquitectura de IBM System z es satisfactoria en mercados que:
•
Tengan cargas antiguas de UNIX que requieran actualizaciones de software y
de hardware o hayan llegado al final de su vida útil. El System z de IBM puede
ser la plataforma ideal para la consolidación de estos entornos.
•
Requieran capacidad bajo demanda para escalar hasta la potencia de proceso
requerida para cargas que experimenten un pico en su actividad. Los clientes
sólo tienen que pagar por la potencia adicional cuando la necesiten.
•
Deban desplegar nuevas cargas y aplicaciones desde el principio que hayan
sido específicamente diseñadas para el Mainframe o destinadas a una
infraestructura, que como el Mainframe, pueda ofrecer rendimiento, fiabilidad y
estabilidad sin parangón.
•
Tengan implementaciones grandes de Linux, Oracle, WebSphere y DB2. Estos
entornos operativos han probado su éxito y consiguen todas las ventajas que la
arquitectura del Mainframe proporciona.
¿Qué pasa con las cargas de Microsoft Windows?
La mayoría de los entornos virtualizados x86 ejecutan cargas de trabajo basadas en
aplicaciones típicas de Microsoft (es decir, Exchange, SQL Server, SharePoint), Oracle
y SAP. Se soportan otros sistemas operativos, que incluyen Linux y Solaris, pero son
una porción muy pequeña del total de entornos virtualizados x86.
Las plataformas Windows no se pueden ejecutar como máquinas virtuales en IBM
System z, al menos no hoy. Para ello, IBM tendría que emular el hardware x86, algo
que podría funcionar en teoría, pero que puede no ser el camino más económico a
seguir por el cliente.
IBM Corporation
21/02/2011
11 de 131
2.3 Escalabilidad
En telecomunicaciones y en ingeniería informática, la escalabilidad es la propiedad
deseable de un sistema, red o proceso, que indica su habilidad para extender el margen
de operaciones sin perder calidad, o bien manejar el crecimiento continuo de trabajo de
manera fluida, o bien para estar preparado para hacerse más grande sin perder calidad
en los servicios ofrecidos.
En general, también se podría definir como la capacidad del sistema informático de
modificar su tamaño o configuración para adaptarse a las circunstancias cambiantes.
La escalabilidad como propiedad de los sistemas es generalmente difícil de definir, en
particular es necesario definir los requerimientos específicos para la escalabilidad en
esos proyectos donde se crea que son importantes. Es una característica altamente
significativa en sistemas electrónicos, bases de datos, ordenadores, routers y redes.
Un sistema escalable es aquél cuyo rendimiento mejora, después de haberle añadido
más capacidad de hardware, proporcionalmente a la capacidad añadida.
2.3.1 Introducción (conceptos de vertical, horizontal y aprovisionamiento)
Hablamos de escalabilidad horizontal cuando para ampliar la capacidad de un sistema
lo que añadimos es otro sistema similar.
Nos referimos a escalabilidad vertical cuando lo que hacemos es aumentar la
capacidad dentro de la misma máquina, por ejemplo aumentando el número de
procesadores.
IBM Corporation
21/02/2011
12 de 131
Aprovisionamiento es el proceso de preparar y configurar cualquier sistema requerido,
proveer a los usuarios del acceso a datos y recursos tecnológicos, y en particular se
refiere a todo el proceso de administración de los recursos requeridos.
2.3.2 Escalabilidad del hardware
Nos referimos a la escalabilidad del hardware cuando hablamos de escalabilidad
vertical. Dentro del System z se obtiene la más alta escalabilidad debido a los múltiples
modelos de máquinas que pueden ir de un solo procesador corriendo en modo de
subcapacidad a 64 que permiten correr hasta 60 imágenes de z/OS.
Como vimos en la parte dedicada a capacidad, éste es un concepto ambiguo cuya
medición depende realmente de lo que se esté haciendo. Por eso es complicado
comparar distintas máquinas corriendo distintos tipos de aplicaciones. Aún así
comparar máquinas puede ser interesante. IBM realiza comparaciones con distintos
tipos de trabajos para sus máquinas del System z y publica los resultados en
http://www-03.ibm.com/systems/z/advantages/management/lspr/index.html.
Si vemos una gráfica comparativa de la familia z10 nos encontramos con lo siguiente
para los modelos z10 BC:
Es decir de 26 a 2760 PCI’s (Procesor Capacity Index). Para los modelos z10 EC nos
encontramos con lo siguiente:
Es decir con una capacidad de 216 a 5848 PCI’s para los modelos en subcapacidad y
de 920 a 30667 PCI’s para los que no corren en subcapacidad. Con esto vemos que
podemos ir de 26 a 30600 PCI’s dentro de la misma familia. Se pueden realizar
IBM Corporation
21/02/2011
13 de 131
cambios de modelo se forma sencilla, algunos incluso sin necesidad de parar la
máquina.
2.3.3 Escalabilidad de los S/O. z/OS z/VM y Linux for System z
La escalabilidad, obviamente, no depende sólo del hardware, el sistema operativo debe
poder administrar esa capacidad. Dentro de la plataforma System z es habitual que en
una misma máquina corran varias imágenes, debido a los distintos tipos de entorno,
como pueden ser producción, desarrollo, test, sistemas, etc. El sistema operativo z/OS
puede administrar miles de millones de transacciones al año, con su habitual
rendimiento y disponibilidad, además de la seguridad implícita
El sistema z/VM funciona generalmente como un programa hipervisor, pudiendo
arrancar huéspedes variopintos, desde z/OS hasta Linux pasando por z/VSE. El Linux
para System z corre habitualmente como un huésped del z/VM, pudiendo generarse
miles de instancias en una sola partición.
2.3.4 Sysplex Paralelo
El Sysplex paralelo nació como una técnica para aumentar la disponibilidad del MVS.
Permite utilizar varias imágenes de z/OS como si fuera un único sistema operativo,
compartiendo entre todas ellas recursos tales como los datos, las impresoras, las
cintas, la base de datos de RACF, etc.
Ésta sigue siendo la característica más importante del Sysplex paralelo, pero como
resultado añadido nos encontramos con que dicha técnica permite una escalabilidad
horizontal con unas propiedades únicas dentro de dicha posibilidad.
El Sysplex paralelo permite unir hasta 32 imágenes de z/OS compartiendo los datos y
actuando como una única imagen sin pérdida de la integridad de los datos. Esto
es lo que no ocurre con el resto de sistemas que se decantan por una escalabilidad
horizontal: cada sistema es responsable de sus propios recursos y estos no se
comparten con el resto.
Un esquema de Sysplex paralelo podría ser el siguiente:
IBM Corporation
21/02/2011
14 de 131
Como característica importante vemos la importancia de tener una única hora en todas
las máquinas, pieza clave a la hora de conseguir integridad en los datos. Hasta ahora
esto venía dado por una máquina especial, el ‘Sysplex timer’, ahora se consigue con un
acoplamiento especial y un protocolo propio, que es similar aunque no igual al SNTP, el
STP.
2.3.5 Capacidad bajo demanda (lo nuevo de z/OS de aprovisionamiento)
Acontecimientos inesperados, tales como incrementos impredecibles en la carga, o
desastres naturales pueden requerir que la capacidad del IT se incremente de forma
inesperada. IBM puede proporcionar la capacidad necesaria sencilla y rápidamente.
Capacity on Demand es el dispositivo clave que permite ajustar la memoria y la
capacidad de proceso a necesidades específicas sin necesidad de apagar o reiniciar el
servidor, y sin tener que realizar un IPL al sistema operativo.
Capacity on Demand (CoD) puede proporcionar subidas de capacidad temporales o
permanentes.
CIU (Customer initiated upgrade), es la propuesta de CoD que permite realizar una
subida de capacidad definitiva en el momento más conveniente para el cliente. Sólo
permite subidas de LICCC, no proporciona subidas de dispositivos de entrada/salida.
Los cambios de capacidad temporales pueden ser de varias clases:
CBU (Capacity Back-up upgrade) es una activación concurrente de capacidad de
proceso para reemplazar la capacidad perdida en una instalación a consecuencia de un
desastre. Esta opción no se puede utilizar para un pico en la carga de trabajo. Puede
utilizarse hasta 90 días después de que el desastre ocurra. También permite realizar 5
pruebas de 10 días al año.
CPE (Capacity for planned events) permite un incremento de capacidad temporal para
reemplazar capacidad perdida temporalmente debida a paradas planificadas, por
ejemplo para realizar cambios en el centro de procesos. No se puede utilizar para picos
de carga o para situaciones de desastre. Puede estar activado durante 72 horas.
ON/OFF Capacity on Demand (On/off CoD) permite subidas temporales de capacidad.
Se trata de la oferta de CoD que permite dirigir los incrementos en la capacidad debida
a picos en la carga de trabajo.
z/OS Capacity Provisionig (CP) ayuda a manejar la capacidad de los procesadores de
System z que corran z/OS. Utilizando la On/Off CoD, se puede activar y desactivar
capacidad temporal basándose en los requerimientos actuales de la carga. z/OS CP
también simplifica la monitorización de cargas críticas y sus posibilidades de
automatización permiten activar recursos adicionales más rápidamente que si se tuviera
que realizar manualmente.
2.4 Integridad y Seguridad
Los programas y los datos de una instalación se deben proteger de accesos no
autorizados –tanto internos (empleados) como externos (clientes, proveedores,
hackers, etc.). Para entender el z/OS, se necesita comprender la importancia de la
seguridad y las funciones que el z/OS utiliza para implementarla.
2.4.1 Integridad
Se define como integridad de un sistema a la capacidad del sistema de protegerse a sí
mismo contra accesos no autorizados hasta el punto en que no se puedan
comprometer los controles de seguridad.
IBM Corporation
21/02/2011
15 de 131
Emitido primero en 1973, el compromiso de integridad del sistema de IBM para el MVS
TM (IBM’s MVS TM System Integrity Statement), y subsecuentemente para el OS/390
y el z/OS, se ha mantenido a lo largo de tres décadas como un símbolo de la confianza
y el compromiso de IBM hacia el sistema operativo z/OS. IBM reafirma su compromiso
con la integridad del sistema z/OS.
El compromiso de IBM incluye prácticas de diseño y desarrollo que pretenden evitar
que programas de aplicación, subsistemas y usuarios no autorizados traspasen la
seguridad del z/OS –esto es, evitar que accedan, eludan, inhabiliten, alteren o consigan
control de procesos claves y recursos del z/OS a menos que tengan permiso de la
instalación-. Específicamente, z/OS “System Integrity” se define como la incapacidad de
cualquier programa no autorizado por un mecanismo bajo el control de la instalación a
eludir o inhabilitar memoria o adquirir protección o acceder a un recurso protegido por
RACF u obtener control de forma autorizada; esto es, en estado supervisor, con una
clave de protección menor de 8, o autorizado APF (Authorized Program Facility). En el
caso en que se reporte un problema en la integridad del sistema, IBM siempre tomará
medidas para solucionarlo.
El largo compromiso de IBM con la integridad del sistema es único en la industria, y
constituye la base del liderazgo del z/OS en la seguridad del sistema. z/OS está
diseñado para ayudar a los clientes a proteger su sistema, sus datos y transacciones de
modificaciones accidentales o maliciosas. Esta es una de las muchas razones que
hacen que el System z siga siendo líder como servidor de cargas de trabajo críticas
para la empresa.
2.4.1.1
Serialización
Es el mecanismo que impide que varios procesos modifiquen a la vez un recurso,
comprometiendo así la integridad de la operación.
GRS (Global Resource Serialization) es el mecanismo que se encarga de serializar los
recursos dentro del z/OS, y puede hacerlo tanto dentro de un único sistema, como a lo
largo de un conjunto de ellos conectados en un GRS (generalmente coincidente con un
SYSPLEX Paralelo)
2.4.1.2
RRS
Resource recovery services (RRS) proporciona un gestor global de sincronización que
cualquier gestor de recursos en el z/OS puede utilizar. Permite a las transacciones
modificar recursos protegidos administrados por diversos gestores de recursos sin
pérdida de integridad.
El RRS se está convirtiendo cada vez más en un prerrequisito para los nuevos gestores
de recursos y para nuevas funcionalidades en los existentes. Más que implementar su
propio protocolo de commit en dos fases, estos productos pueden utilizar el soporte que
proporciona el RRS.
2.4.1.3
Backups
Para proporcionar una integridad en los datos tener copias de back-up de los ficheros,
no es condición suficiente, aunque sí necesaria. Para poder asegurar la integridad ante
un fallo, es necesario recurrir a técnicas de apunte de las transacciones ejecutadas
entre puntos de sincronismo. Tanto el DB2, como el CICS, como el resto de gestores
que hagan uso del RRS, disponen de dichas técnicas, que permiten recuperar los datos
a un punto de sincronismos, es decir, sin pérdida de integridad,
IBM Corporation
21/02/2011
16 de 131
2.4.2 Seguridad
Acceder y crear información computerizada se ha hecho más fácil a lo largo del tiempo.
El acceso a los sistemas hace tiempo que dejó de estar limitado a un pequeño grupo de
programadores especializados. Cualquier persona que se tome la molestia de
familiarizarse con los nuevos lenguajes de búsqueda, puede tener acceso a la
información, contenida en los modernos medios puestos a su alcance, e incluso puede
crearla en dichos medios.
La gente depende cada vez más de los ordenadores y de la información que se guarda
en ellos. A medida que la alfabetización informática y el número de gente que usa los
ordenadores se incrementan, la necesidad de la seguridad de los datos ha adoptado un
nuevo y dramático cariz. Las empresas ya no pueden confiar en que tienen sus datos
seguros simplemente porque nadie sabe como llegar a ellos.
Proteger los datos es algo más que hacer inaccesible la información confidencial a
aquéllos que no debieran verla. También incluye la prevención de la destrucción
inadvertida de ficheros por gente que puede incluso no ser consciente de que estén
manipulando datos incorrectamente. Las buenas prácticas de seguridad reducen los
riesgos de que personas no autorizadas puedan acceder a los datos, modificarlos o
destruirlos, tanto de forma inadvertida o como deliberada.
El acceso, en un entorno informático significa la habilidad para realizar algo con un
recurso del ordenador (por ejemplo, utilizar, cambiar o ver un fichero). El control de
accesos es el método por el cual se permite o prohíbe expresamente dicha capacidad.
Este tipo de acceso se denomina acceso de control lógico. Estos son mecanismos de
control que permiten a los usuarios acceder sólo a aquello que es apropiado para
ellos...
Los accesos de control lógicos se construyen generalmente dentro del propio sistema
operativo, aunque también pueden ser parte de la lógica de la aplicación o de
determinadas utilidades, tales como los sistemas gestores de bases de datos. También
se puede implementar a través de paquetes de seguridad que se instalan sobre el
sistema operativo, dichos paquetes están disponibles para una gran variedad de
sistemas, incluyendo los PC’s y los Mainframe. Además, los controles lógicos de
acceso pueden estar presentes en componentes especializadas que regulan las
comunicaciones entre ordenadores y redes.
Las facilidades que incorpora el z/OS proveen de su alto nivel de seguridad e
integridad. El System z es el único en poseer la calificación EAL5 de seguridad.
Los datos acerca de los clientes son una información vital dentro de los activos de una
empresa. Dicha información podría ser vendida a los competidores con grave trastorno
para el funcionamiento de dicha empresa. Así el objetivo de cualquier política de
seguridad es dar a los usuarios sólo el requerido nivel de acceso y denegar los accesos
no autorizados. Esta es una de las razones por las cuales los auditores de seguridad
prefieren que se otorgue a los usuarios o grupos un acceso específico, más que utilizar
facilidades de acceso universal. El objetivo tradicional en la seguridad del Mainframe
era el impedir a personas no autorizadas el acceso al sistema, y después conseguir
darles permiso únicamente a los datos pertinentes a su trabajo. A medida que los
Mainframe se están convirtiendo en servidores de Internet se requieren medidas
adicionales de seguridad. Existen peligros externos tales como hackers, virus y caballos
de Toya; el servidor de seguridad debe incluir herramientas para enfrentarse a dichos
problemas.
Sin embargo, frecuentemente el mayor riesgo paro los datos de la compañía viene de
dentro. Un empleado dentro de una empresa tiene muchas más oportunidades de
obtener datos que alguien externo. Una política de seguridad bien implementada es
siempre la primera línea de defensa.
IBM Corporation
21/02/2011
17 de 131
El z/OS contiene un conjunto de características de integridad del sistema que minimizan
los daños intencionados o accidentales de otros programas. Por ejemplo, muchas
instalaciones tienen diversas imágenes de z/OS y frecuentemente no permiten el
acceso de usuarios de TSO/ISPF a los sistemas de producción.
En cualquier caso los controles de seguridad del z/OS pueden proteger los entornos de
producción si se configuran convenientemente y prevenir que usuarios de TOS/ISPF
(accidental o maliciosamente) Impacten el importante trabajo de producción.
2.4.2.1
Control de programas con privilegios (APF)
APF (authorized program facility) se emplea para permitir a la instalación la
identificación de programas, ya sean de usuario o de sistemas, que puedan utilizar
funciones sensitivas del sistema. Para mantener la integridad y seguridad del sistema,
un programa debe estar autorizado por el APF antes de que pueda acceder a funciones
restringidas, tales como ejecutarse en modo sistema. Ayuda a evitar riesgos de la
integridad; siendo la instalación la que identifica qué librerías contienen funciones
especiales. A estas librerías se les denomina librerías APF.
Un programa autorizado puede hacer virtualmente cualquier cosa que quiera. Es
esencialmente una extensión del sistema operativo. Se puede poner en estado
supervisor o con clave de sistema. Puede modificar los bloques de control del sistema.
Puede ejecutar instrucciones privilegiadas (mientras esté en estado supervisor). Puede
suspender el diario para cubrir sus trazas. Claramente esta autorización debe darse con
moderación y monitorizarse cuidadosamente.
Una instalación puede utilizar el APF para identificar programas de usuario o sistema
que puedan ejecutar funciones sensitivas de sistema. Por ejemplo, APF permite a una
instalación restringir la utilización de rutinas sensitivas de SVC, a programas APF.
También permite al sistema que cargue todos los módulos en un trabajo autorizado sólo
de librerías autorizadas, para prevenir que programas puedan cargar módulos que no
sean los correctos.
2.4.2.2
Control del acceso a memoria (Claves de protección de la memoria)
El hardware del System z tiene una función de protección de memoria, que se emplea
generalmente para evitar la modificación no autorizada de la memoria. La protección de
memoria también se usa para prevenir la lectura no autorizada de áreas de memoria,
aunque el z/OS protege sólo pequeñas áreas de memoria de esta forma.
La protección de memoria trabaja con páginas de 4K. Trata sólo con memoria real, no
virtual. Cuando una página de memoria virtual se copia del disco a una página libre de
la memoria principal, z/OS aplica la adecuada clave de protección en dicha página.
La protección de memoria era mucho más importante cuando no existían los múltiples
espacios de direcciones. Cuando varios usuarios y trabajos compartían un único
espacio de direcciones (o estaban todos en memoria real antes aún), proteger la
memoria del usuario para evitar la corrupción (o la lectura inapropiada) era esencial.
Con el z/OS, la primera protección para la memoria de cada usuario es el aislamiento
proporcionado por los múltiples espacios de direcciones.
Los programas de aplicación no pueden alterar las claves de protección de la memoria.
No existe forma, utilizando la función de protección de memoria, de que un programa de
aplicación normal (no un programa autorizado) pueda proteger parte de su memoria
virtual de otras partes de la aplicación corriendo en el mismo espacio de direcciones.
Un bit adicional de protección de memoria (para cada página de 4K de memoria real) es
el bit de protección de página. Este previene que incluso las rutinas del sistema (que
corren con clave 0, lo que habitualmente les permite escribir en cualquier sitio) puedan
IBM Corporation
21/02/2011
18 de 131
almacenar datos en esa página. Este bit se utiliza generalmente para proteger páginas
de la LPA de daños inadvertidos causados por las rutinas del sistema.
2.4.2.3
Control del uso de instrucciones privilegiadas (Llamadas al Supervisor (SVCs))
La ejecución de instrucciones en el sistema, está protegido por un mecanismo al que
llamamos estados de ejecución.
Existen dos posibles estados: Estado problema y estado supervisor. La mayoría de las
instrucciones se pueden ejecutar en estado problema, aunque hay algunas (referentes
al uso de de registros de control, al uso de E/S, etc.…) que exigen estado supervisor.
Para evitar el uso indiscriminado del estado supervisor (por los riesgos que acarrea)
existen unos APIs llamados SVC (Supervisor Calls) que fuerzan a los programas a
utilizar las operaciones restringidas de manera controlada.
2.4.2.4
SAF
SAF (System authorization facility) es una interfaz definida por el MVS que permite a los
programas utilizar servicios de autorización del sistema para controlar el acceso a
recursos, tales como ficheros y comandos de MVS. SAF o bien procesa las
autorizaciones de seguridad directamente o trabaja en conjunto con el RACF, u otro
producto de seguridad, para llevarlas a cabo.
2.5 Rendimiento
Según la Real Academia de la Lengua, rendimiento es el producto o utilidad que rinde o
da alguien o algo, o la proporción entre el producto o el resultado obtenido y los medios
utilizados. Como siempre, en el lenguaje de los ordenadores estas definiciones no son
exactas. Como rendimiento entendemos lo ‘afinado’ que está un sistema, si las
expectativas que tenemos acerca de lo que puede proporcionar, se corresponden con
la realidad, o más exactamente, si el tiempo de respuesta que conseguimos es el
adecuado.
En un sistema operativo como el z/OS, que realiza múltiples aplicaciones, cada una con
sus expectativas dispares, afinar el sistema no parece una tarea simple. Pero las
facilidades que ha ido incorporando el z/OS a lo largo de los años hacen que cada día
resulte más sencillo disponer de un sistema con un rendimiento inigualable.
Entre estas facilidades destaca el WLM, (Work Load Manager), que permite definir los
objetivos de las aplicaciones en un lenguaje acorde con los compromisos de servicio
pedidos por los usuarios (SLA’s). El WLM se encarga de proporcionar los recursos
necesarios para conseguir los objetivos acordados.
También se dispone del RMF, que permite obtener informes, e incorporarlos a hojas de
cálculo, para comprobar que se cumplen los objetivos y detectar posibles fuentes de
problemas si es que se incumplen.
IBM Corporation
21/02/2011
19 de 131
2.6 Disponibilidad
La solidez1 se considera como una de las propuestas de valor más importantes de la
plataforma, y los estrategas del negocio generalmente consideran System z como la
plataforma más robusta.
Este apartado comienza con el debate sobre el coste del tiempo de parada y la
necesidad de flexibilidad para luego continuar detallando las ventajas intrínsecas que
convierten la plataforma System z en resistente, que incluyen:
•
Las características fundamentales del hardware que hacen del System z una
máquina capaz de proporcionar una disponibilidad fuera de clase.
•
Funciones que ayudan a la empresa a eliminar las interrupciones planificadas
tanto para los cambios de hardware como de software.
•
Características de diseño del z/OS, Sysplex paralelo y GDPS, y cómo éstas
mejoran la flexibilidad de la plataforma System z.
2.6.1 Construido para los negocios.
El coste de inactividad es alto, lo cual obliga a las empresas a intentar evitar cualquier
tipo de paradas. Una empresa debe recuperarse rápidamente de todas las
interrupciones, ya sean planificadas o no. Casi nada es peor que ser sorprendido por
una caída del sistema, incluso si la duración de ésta son sólo algunos minutos.
Considere cómo una interrupción inesperada, provocada quizás por una catástrofe
natural o un fallo menor en el software, puede poner en juego las relaciones con los
clientes, la productividad, y posiblemente millones de dólares, si aplicaciones y datos
vitales quedan desprotegidos.
La resiliencia de los negocios, que se puede considerar como la capacidad de una
empresa para seguir funcionando eficazmente ante errores informáticos o humanos y
desastres que afecten a su IT, ha sido una de las tres propuestas de valor más
importantes del centro de procesos, junto con la competitividad y el ahorro de costes.
Los estrategas empresariales normalmente consideran el entorno System z como la
plataforma más robusta, con cuya solidez se puede contar. Actualmente dicha solidez
debe estar integrada con el resto de sistemas de la empresa para lograr los objetivos de
resiliencia de los negocios. La plataforma System z, con sus características de
disponibilidad y fiabilidad, es una plataforma ideal a partir de la cual construir una
infraestructura robusta y desde la cual probar nuevas tecnologías y estrategias de
resistencia.
Algunas plataformas pueden haberse diseñado originalmente para fines académicos u
otros propósitos, pero la plataforma System z fue creada como una solución para las
empresas. Durante los años, las tecnologías de resiliencia han evolucionado y se han
ido incorporando al diseño fundamental del sistema z. Hoy, la plataforma z continúa
innovando y mejorando su tecnología de resiliencia. La solidez es imprescindible para la
línea de negocios de una empresa y el sistema z es la mejor plataforma para garantizar
que los sistemas comerciales se mantendrán funcionando a lo largo de una
recuperación ante un desastre, de una reparación o actualización, y también ante
cambios en el software y las aplicaciones.
1
Solidez flexibilidad y resistencia se emplean como la traducción del término inglés ‘resiliency’,
de difícil traducción en este contexto. Es la capacidad que tiene un sistema de recuperarse ante
fallos imprevistos.
IBM Corporation
21/02/2011
20 de 131
2.6.2
Una solución para la operación continúa de los negocios.
La inactividad es costosa. El coste de las paradas es tan grande que muchas de las
empresas de hoy ya no pueden permitirse las interrupciones, planificadas o no. Las
estadísticas dicen que las empresas pueden perder entre decenas de miles a varios
millones de dólares por hora de inactividad. Incluso más allá de los aspectos
financieros, la inactividad también puede afectar a áreas clave como la fidelidad de los
clientes, la competitividad en el mercado, y la conformidad legislativa. Por ejemplo, si un
sitio Web no está accesible, los clientes de Internet irán a otra parte. La operación
continua es un imperativo empresarial, y requiere tener lo mejor en tecnología robusta.
Algunas empresas deben parar sus sistemas para realizar actualizaciones planificadas,
aplicar mantenimiento, o renovar sus servidores. Características incorporadas en la
plataforma System z, sin embargo, permiten a las empresas evitar estas interrupciones
planificadas. Además de ser una solución excelente para la eliminación de las paradas
planificadas, System z es también una excelente plataforma para evitar interrupciones
no planificadas. Con tecnologías tales como el Sysplex paralelo y GDPS, el System z
proporciona una cobertura ante un desastre única en el mercado, pudiendo recuperar
sus sistemas con un RTO y RPO preestablecidos, y ofreciendo procedimientos
estándar ante fallos generales y la posibilidad de crear sus propios escenarios de una
forma sencilla y comprobable.
2.6.3 Disponibilidad y fiabilidad de primera clase
Cada minuto, el ritmo de crecimiento de los negocios mundiales aumenta y el volumen
de datos crece. Las empresas necesitan mantenerse operando 24x7 y superar
problemas tales como un mayor tráfico en la red, picos de carga imprevisibles, y bases
de datos difíciles de controlar. Los componentes del System z, hardware, firmware,
middleware y los sistemas operativos están diseñados, y estrechamente integrados,
para proporcionar un entorno de aplicación, con un nivel único en el mercado, para la
alta disponibilidad. System z proporciona las mejores tecnologías para asegurar la
disponibilidad y fiabilidad.
La disponibilidad del sistema puede medirse en distintos contextos. Una medida común
es la disponibilidad de hardware contra las interrupciones no planificadas. Una medida
más estricta de la disponibilidad examina las aplicaciones a nivel de usuario, incluyendo
las interrupciones planificadas. Medir la disponibilidad desde la perspectiva del usuario
requiere la consideración del hardware, OS, middleware y aplicaciones. El Sistema z se
mantiene en las más estrictas medidas y puede lograr una disponibilidad de primera
clase a nivel de usuario.
IBM Corporation
21/02/2011
21 de 131
2.6.4
Fortalezas del corazón del hardware.
El Sistema z, construido para la recuperación y la operación continuas, es un servidor
de alta disponibilidad. El resultado de la atención a la solidez es un punto de diseño
llamado tiempo medio entre fallos (MTBF). El sistema z está diseñado para ofrecer
capa sobre capa de tolerancia a los fallos y puntos de comprobación de errores. Si se
produce una anomalía, la redundancia construida en la plataforma cambia el trabajo
desde el componente anómalo a otro operativo para evitar que la aplicación o el
servicio de usuario queden interrumpidos. Además, los componentes que hayan fallado
se pueden reemplazar mientras las aplicaciones están activas y siguen funcionando,
eliminando tiempo de parada.
Los errores se pueden producir por muchas causas. Hay errores transitorios, debidos a
las condiciones del medio ambiente como ruido o partículas cósmicas, y errores más
permanentes, como fallos de hardware. Los productos de System z están diseñados
para enfrentarse a estas diversas circunstancias. La detección y corrección de errores
está construida dentro de la lógica para detectar errores en memoria y corregirlos.
Tecnologías similares ayudan a encontrar los problemas en el primer momento posible
y habilitan el entorno System z para que adopte las acciones necesarias para
corregirlos, ayudando así a minimizar el impacto que puedan causar en las
aplicaciones. La estrategia de System z también se centra en un diseño de
recuperación de errores que los enmascare y los haga transparente a las operaciones
del cliente. Una amplia tecnología de la recuperación está incorporada en el hardware.
A lo largo de los años, más y más dispositivos se han ido añadiendo para mejorar la
solidez y flexibilidad el la plataforma System z. Las versiones más recientes, el
hardware del sistema z9 y z10, incorporan tecnologías únicas que aplican las más
modernas innovaciones en la tecnología de la resiliencia.
2.6.4.1
Redundancia
La redundancia es quizás el mecanismo más frecuente para garantizar la solidez, y es
un tema clave en toda la plataforma System z. Los diseñadores del sistema z han
trabajado a lo largo de los años para eliminar cualquier punto único de fallo. La
plataforma tiene muchos componentes redundantes. Por ejemplo, hay dos tomas de
corriente que permiten al sistema sobrevivir a la pérdida de uno de ellos. Hay dos
MRUs (Módulo De Refrigeración de Unidades). El subsistema de servicios, la batería
interna, el oscilador y todos los procesadores son redundantes. Considere un sistema
z9 completamente lleno: 54 procesadores centrales, ocho SAP, dos CP de respaldo y
336 PowerPC para los canales FICON, Suman un total de 400 procesadores.
Después de tener en cuenta la redundancia, ese mismo sistema podría tener 800
procesadores.
2.6.4.2
Eliminación de paradas planificadas mediante cambios concurrentes en el
hardware
En el pasado, frecuentemente las empresas tenían que cerrar un sistema las noches de
los sábados para realizar cambios o mantenimiento en el hardware. Hoy la plataforma
System z elimina dichas paradas planificadas con su capacidad para cambiar el
hardware sin que afecte a la aplicación. La capacidad de realizar cambios concurrentes
ayuda al System z a dar servicio a sus usuarios en cualquier momento, 24x7, sin
paradas planificadas para mantenimiento de los datos o del sistema.
En el mundo de los negocios actuales, los backups y el mantenimiento de los sistemas,
tales como subidas de nivel o cambios, se deben realizar sin interrumpir las
operaciones. Muchos componentes del System z se pueden mantener y subir de nivel
de concurrentemente, incluyendo los procesadores, books, memoria, tarjetas
criptográficas y canales de la CF. Incluso elementos no redundantes como las tarjetas
IBM Corporation
21/02/2011
22 de 131
de canal se pueden enchufar en caliente, y reemplazar sin ningún impacto en la
aplicación.
2.6.5
Mas allá del hardware
La solidez del System z va mucho mas allá del hardware. El punto focal del diseño de la
flexibilidad del System z son las aplicaciones, esto da como resultado un entorno
integrado donde el hardware, firmware, sistema operativo y middleware trabajan en
conjunto para proveer de disponibilidad a la aplicación y a los datos.
2.6.5.1
z/OS
El sistema operativo z/OS incluye un comprensivo conjunto de capacidades que provee,
junto al hardware del System z, una calidad de servicio única. Con z/OS, la mayoría de
los problemas quedan enmascarados totalmente de las aplicaciones, y en los casos en
que el daño sea severo resulta en una degradación paulatina más que en una completa
parada. z/OS tiene una disponibilidad, fiabilidad, escalabilidad, flexibilidad e integridad
sin parangón. Más aún, lleva mucho tiempo siendo el servidor de referencia para
servidores de datos y transaccionales, y también uno de los preferidos para
aplicaciones Web que requieran la más alta calidad de servicio.
La filosofía del diseño del z/OS requiere un aislamiento, identificación y recuperación de
los errores comprensible. Todos los componentes y subsistemas del z/OS disponen de
rutinas de error. Más aún, todo el código del z/OS sigue unas guías que contienen un
conjunto de normas para la disponibilidad y el servicio. Por diseño, si una aplicación
falla, el trabajo puede continuar en un backup de la aplicación corriendo en el mismo
hardware físico. Además, el z/OS provee de un dispositivo basado en políticas
predefinidas por la instalación que permite la recuperación automática y el arranque de
los servicios transaccionales.
El software del z/OS también tiene un compromiso total con la integridad. Utilizando
técnicas tales como claves de memoria y múltiples espacios de direcciones, los datos y
las funciones del sistema están protegidos contra accesos no autorizados. Con un twophase-commit a nivel sistema, los datos de la aplicación del cliente se pueden
recuperar incluso cuando ocurran fallos a nivel de hardware o software. Algunas
funciones se diseñan además para soportar middleware clave, como el CICS, lo cual
permite altos niveles de disponibilidad para la ejecución de transacciones.
2.6.5.2
z/VM
Además del principal sistema operativo, z/OS, el sistema operativo z/VM tiene muchas
componentes internas para la solidez.
Aquéllos familiarizados con el Linux para el System z probablemente hayan oído la
historia de ese usuario que arrancó, como ejercicio de prueba de concepto, miles de
instancias de Linux en un procesador de z9.
Este hecho demuestra la gran escalabilidad de System z (número de máquinas de
Linux es impresionante) y también, aunque sea menos espectacular, la fiabilidad
demostrada por el z/VM: Cuándo el z/VM se queda sin recursos (cosa que,
evidentemente ocurre al arrancar miles de instancias), no se cae, sigue funcionando a
un nivel aceptable de rendimiento, repartiendo sus recursos de la mejor manera posible.
2.6.5.3
Eliminación de paradas planificadas.
Además de los numerosos métodos para evitar las paradas no planificadas, El System
z tiene métodos para eliminar las pardas planificadas debidas a las subidas de firmware
y a las reconfiguraciones.
IBM Corporation
21/02/2011
23 de 131
Clientes que tienen aplicaciones críticas, generalmente aquéllos que no disponen de un
entorno Sysplex, tienen dificultades para encontrar el tiempo necesario para añadir
nuevas funcionalidades. En el System z, un dispositivo conocido como ‘Enhanced
Driver Maintenance’ (o ‘Concurrent Driver Upgrade’) permite a los clientes subir el
firmware hasta el siguiente nivel sin impactar en el trabajo. El ‘Enhanced Driver
Maintenance’ permite subidas del LIC para CP’s, IFL’s, ICF’s, zAAP’s, zIIP’s, memoria y
adaptadores de E/S de forma transparente para la aplicación.
También es posible realizar reconfiguraciones de la E/S sin tener que planificar una
parada. Esta capacidad de reconfiguración se denomina ‘Dynamic I/O Reconfiguration’,
y permite añadir, borrar o modificar definiciones de canales, unidades de control y
dispositivos de E/S a las configuraciones hardware y software.
2.6.5.4
Sysplex paralelo
El Sysplex paralelo se basa en la fortaleza del Systems z para dar incluso una mayor
disponibilidad y flexibilidad a la hora de las paradas tanto planificadas como
imprevistas. El Sysplex paralelo no es un producto, sino una serie de colaboración entre
distintos sistemas z/OS. El enfoque único de cluster del Sysplex paralelo permite que la
topología de escala de múltiples servidores parezca una única y masiva configuración
de SMP (Symmetric Multiprocessing).
La arquitectura de Sysplex paralelo permite a un conjunto de System z’s la compartición
de recursos, el balanceo de cargas y la compartición de datos para centros de datos a
la carta, ofreciendo lo último en flexibilidad y soportando a la vez diferentes topologías
de aplicación.
Podemos pensar en el Sysplex paralelo como si fuera una orquesta sinfónica, con cada
clase de instrumento representando un producto distinto en el Sysplex. Hay varias de
cada instrumento, igual que puede haber varias imágenes del mismo producto en un
Sysplex. Todos los violines, por ejemplo, suenan igual y tocan la misma parte. Hay
suficientes violinistas para que en caso de que uno caiga enfermo, no se vea afectado
el concierto. Y si dicho violinista dimite, pueda ser reemplazado. De modo similar en un
Sysplex, todos los sistemas, o un subconjunto de ellos, son similares y realizan el
mismo trabajo. Un Sysplex exhibe análogas características de disponibilidad: un fallo o
una desconexión planificada de un sistema del Sysplex no resultará en la pérdida de la
aplicación o en la disponibilidad de los datos, sólo en una pérdida temporal de
capacidad.
Otra ventaja de la tecnología del Sysplex paralelo es su capacidad para instalar o
mantener hardware o software sin interrupciones. Se pueden quitar o añadir servidores
mientras la aplicación continúa corriendo en otros sistemas. Diferentes sistemas
pueden estar corriendo a distintos niveles de software, haciendo de este modo las
modificaciones de software más fáciles. El software se puede modificar en un sistema
mientras el resto permanece disponible. Los cambios más importantes de software se
pueden realizar utilizando la técnica del “rolling IPL” durante la etapa de los cambios sin
necesidad de interrumpir la disponibilidad de la aplicación.
Con la técnica de cluster del Sysplex paralelo y su habilidad para soportar la
compartición de datos entre servidores, los arquitectos de IT pueden diseñar y
desarrollar aplicaciones que tengan una vista integrada de los datos, eliminando
efectivamente la necesidad de dividir las bases de datos. La compartición de datos del
Sysplex paralelo ofrece la ventaja única de permitir el crecimiento de la base de datos
sin interrupciones y con balanceo de cargas automático. En un entorno de bases de
datos particionadas, el crecimiento de la base de datos o de la aplicación requeriría un
tiempo de parada largo y un trabajo de re-particionado complejo. Las capacidades del
Sysplex paralelo ayudan a evitar los obstáculos que se encuentran con la arquitectura
de las bases de datos particionadas.
IBM Corporation
21/02/2011
24 de 131
El middleware del System z explota las capacidades del Sysplex paralelo para
proporcionar una operación continua de las aplicaciones. CICS Transaccion Server,
DB2 for z/OS, WebSphere MQ, WebSphere Application Server, IMS Transaction
Manager, TCP/IP, VTAM, APPC/MVS, RACF son algunos de los productos de IBM que
explotan la tecnología de Sysplex paralelo.
2.6.5.5
GDPS
Imagina por un momento una sala de operaciones de un centro medio inmediatamente
después de un fallo básico del sistema. Los teléfonos suenan, los directores merodean
para saber cuándo estará todo recuperado, los operadores buscan procedimientos, y
los técnicos de sistemas se pelean con los operadores por el control de las consolas.
Ahora imagina en su lugar un escenario donde la única operación manual requerida es
confirmar si se debe continuar con un procedimiento de recuperación ya probado. Este
escenario de recuperación suave, requiere una solución de negocio tal como la
proporciona el GDPS.
GDPS, la solución principal de IBM para la alta disponibilidad, ofrece soluciones de
continuidad tanto para fallos de sistema como para situaciones de recuperación ante
desastres. Basado en la separación geográfica y en técnicas de automatización
avanzadas, el GDPS es una aplicación multi-centros que ofrece la capacidad de
manejar de forma remota la configuración de subsistemas de almacenamiento,
automatizar tareas de operación del Sysplex paralelo y realizar la recuperación desde
un único punto de control. Extiende la compartición de recursos, el balanceo de cargas
y la disponibilidad continua del Sysplex paralelo. También mejora significativamente la
capacidad de una empresa de recuperarse ante un desastre y otros fallos y mejorar las
excepciones a los cambios planificados.
GDPS es una solución para entornos que necesiten proteger y minimizar los riesgos
operacionales. Dos requerimientos de negocio claves que se deben tener en cuenta a
la hora de analizar el GDPS son:
Recovery Time Objetive (RTO), el tiempo que un negocio puede permitirse esperar para
que sus servicios de IT se recuperen después de que haya ocurrido un desastre.
Recovery Point Objective (RPO) que representa la cantidad de datos que un negocio
debe recuperar en el caso de un desastre. Por ejemplo, para un RPO de seis horas, el
objetivo podría ser restaurar los sistemas al estado en el que estaban seis horas antes.
Ambos, el RTO y el RPO son factores importantes a la hora de diseñar una solución de
GDPS. Cualquier recurso que no pueda ser reemplazado en el RTO debería estar
disponible en varias localizaciones, y esto no significa sólo edificios y hardware sino
también empleados y datos. Clientes que desean un RPO de cero, es decir, que no se
pierdan datos, requerirá una solución de copia remota síncrona, como la que provee el
GDPS/PPRC, una de las diferentes soluciones del GDPS.
Además la tecnología de GDPS puede administrar un entorno heterogéneo de datos de
z/OS y entornos abiertos. Esto es importante para la solución habitual de aplicaciones
multi-tier que tienen dependencias de distintas arquitecturas de sistemas.
2.7 Gestión de Sistemas
Vamos a ver los principios de la administración de sistemas y su evolución desde un
proceso casi manual hasta uno donde el ordenador se puede auto-adaptar y cambiar el
sistema de acuerdo con políticas de negocio.
IBM Corporation
21/02/2011
25 de 131
2.7.1 Revisión de la administración de sistemas.
El entorno de IT es más complejo que nunca y los recursos que se requieren para
administrar esos sistemas son cada vez más difíciles de encontrar. La creciente
complejidad del hardware y el software de los sistemas modernos han alcanzado un
punto en el que las personas no pueden, razonablemente, gestionarlos con los métodos
tradicionales.
Administración de sistemas es la administración a lo largo de la compañía de los
sistemas de ordenadores, incluyendo el hardware, los sistemas operativos, el
middleware, las aplicaciones y los subsistemas de almacenamiento. La administración
de sistemas consiste en los procesos, técnicas y herramientas que se requieren para
manejar dichos sistemas. El hardware y software del System z ofrece un conjunto
robusto de herramientas de administración para ayudar a los profesionales de IT a
monitorizar, administrar y automatizar sus sistemas.
La administración de sistemas, una de las fortalezas del z/OS, proporciona uno de los
pilares fundamentales que dan el valor añadido del z/OS. En el entorno de mezcla de
tipos de trabajo que soporta el System z, los recursos del sistema se utilizan en una alta
capacidad, eliminando recursos inactivos tales como CPU’s sin uso o memoria
infrautilizada a la espera de que lleguen los datos.
El objetivo del sistema z/OS es que sea cada vez más fácil de utilizar, incrementar la
disponibilidad de las aplicaciones y reducir los requerimientos y el coste de la
administración del sistema proporcionando una solución ‘end-to-end’.
2.7.2
El valor de la administración de sistemas en el z/OS
z/OS tiene una larga historia en la administración de sistemas y esta es una de las
fortalezas más valoradas del System z.
Aparte el System z tiene la habilidad de realizar el mantenimiento y la instalación tanto
de hardware como de software de forma ininterrumpida en un entorno de Sysplex
paralelo.
2.7.2.1
Alta disponibilidad y subidas de nivel
Con los sistemas configurados como un Sysplex paralelo, se pueden añadir o eliminar
sistemas dinámicamente al conjunto, permitiendo la instalación de un nuevo hardware o
el mantenimiento del existente. Mientras tanto, el resto de sistemas continúa el trabajo.
IBM también tiene una política de co-existencia que permite las subidas de hardware y
software con hasta tres versiones previas de z/OS. Esto permite a los clientes añadir
nuevo hardware sin necesidad de subir de nivel el sistema operativo en todas las
máquinas del Sysplex.
El middleware de IBM también co-existe con la versión previa, dando a los arquitectos
de software la oportunidad de decidir cuando cambiar el middleware basándose en las
políticas de negocio y no en el momento del cambio del hardware.
z/OS también permite realizar mantenimiento de hardware y software de una manera
escalonada, denominada ‘rolling’, de forma ininterrumpida. Esto permite a las empresas
implementar funciones críticas para el negocio y reaccionar a un crecimiento rápido sin
afectar a la disponibilidad del sistema.
2.7.2.2
Datos contables integrados.
Un centro de datos debe mantener un registro de sus recursos para poder determinar
así sus gastos y que éstos puedan ser atribuidos a las distintas unidades de negocio.
IBM Corporation
21/02/2011
26 de 131
En el entorno distribuido se suele mantener el ratio aplicación/servidor uno a uno para
que el centro de proceso pueda mantener este registro de gastos. Este modelo puede
llegar a ser muy caro a causa de la baja utilización de los recursos de los sistemas, el
aumento del espacio requerido, el crecimiento en la utilización de energía, etc. En el
z/OS, si una aplicación está ociosa, los recursos se pueden dar a otra. El System
Management Facility (SMF) proporciona un registro a nivel de sistema que permite
distintas funciones. Entre ella destaca la de contabilidad, que permite atribuir a cada
tarea la cantidad de recursos consumida. Cualquier componente del sistema, o
programa que lo desee, puede hacer uso de la facilidad del SMF
La información que mantiene el SMF se puede utilizar para:
Facturar a los usuarios.
Informes de fiabilidad
Análisis de la configuración
Informes de la actividad de los discos
Analizar el uso de los recursos del sistema.
Auditar la seguridad del sistema.
Etc.
Para más información acerca del SMF, véase ‘z/OS VxRx MVS System Management
Facilities’, SA22-7630
2.7.2.3
Administración de recursos
El Resource Measurement Facility (RMF) es el administrador y calibrador de los
recursos estándar del z/OS. El RMF está diseñado para simplificar el manejo de uno o
varios tipos de cargas. Con el RMF, se puede detectar un potencial cuello de botella
antes y se pueden evitar o minimizar los retrasos que pudiera llegar a producir. El RMF
utiliza los registros del SMF para realizar medidas de rendimiento y adaptar recursos
tales como CPU, memoria, paginación, dispositivos de E/S, CF, cintas, memoria virtual,
contenedores de XCF, colas del sistema….
El RMF proporciona los informes que se necesitan para entender el rendimiento de un
Sysplex desde un único punto de vista. Utiliza objetivos integrados con los negocios
para determinar si el sistema está alcanzando sus objetivos de rendimiento.
El RMF permite cargar sus informes en aplicaciones de hojas de cálculo e integrar
datos históricos de rendimiento.
2.7.3 Iniciativa del ordenador autónomo de IBM
Los ordenadores no se convierten en autónomos de la noche a la mañana. Este es un
proceso que evoluciona a lo largo del tiempo. Prueba y error van conformando las
mejores estrategias. Para que un ordenador pueda ser autónomo, la lógica de estas
estrategias debe estar incluida en la lógica del software. Los sistemas autónomos
evolucionan a lo largo del tiempo a medida que los diseñadores de sistemas aprenden
a predecir y arreglar los problemas. Los negocios incorporan los principios autónomos
despacio en su infraestructura de IT. La madurez autónoma es un continuo de las
propiedades auto-administrativas de un sistema. Existen cinco niveles de madurez
autónoma: básico, administrado, predictivo, adaptativo y autónomo.
IBM Corporation
21/02/2011
27 de 131
Básico-Los profesionales de IP administran cada elemento de la infraestructura
independientemente.
Administrado-Se utilizan técnicas de administración de sistemas para reunir información
en menos consolas.
Predictivo-Se introducen procesos analíticos en el sistema para monitorizar las
situaciones que surjan y se analizan éstas para proporcionar posibles cursos de acción,
pero el profesional de IT decide lo que hay que hacer.
Adaptativo-El entorno de IT puede ejecutar acciones basadas en la información
disponible y el conocimiento de lo que está sucediendo en el sistema.
Autónomo-Políticas de negocio y objetivos gobiernan la operación de la infraestructura
de IT. Los profesionales de IT monitorizan los procesos de negocio, no los procesos de
IT, y alteran los objetivos del sistema basados en las políticas de negocio.
En el mercado actual hay ejemplos de sistemas predictivos y adaptativos, pero la
mayoría continúan en un nivel básico o administrado. z/OS está continuamente
reforzando sus capacidades autónomas con el objetivo de llegar a un sistema
totalmente autónomo.
Actualmente los productos de System z incorporan una amplia variedad de capacidades
autónomas basadas en las cuatro características de los sistemas auto-administrados:
auto-configurado, auto-reparador, auto-optimizante y auto-protegido.
2.7.4 Tecnologías auto-configuradoras.
z/OS no es todavía totalmente auto-configurado, pero sí dispone de ‘dynamic
configuration’ lo cual significa que se puede cambiar la configuración mientras el
sistema está activo.
Con la plataforma System z, un centro de procesos no tiene que subir de nivel el
sistema operativo cuando añade una máquina nueva. El hardware de System z siempre
podrá correr la release actual y las tres anteriores de z/OS. (Para el middleware es la
actual y la anterior) Esto permite a los centros de procesos reducir la complejidad de las
modificaciones pudiendo elegir actualizar primero el hardware y más tarde el software y
el middleware.
El z/OS no requiere paradas para realizar cambios en la configuración incluso aunque
haya más de una imagen en el sistema. Las tecnologías de auto-configuración no
intentan simplificar la complejidad del z/OS, solo simplificar su configuración. El z/OS
dispone de herramientas para ayudar en la configuración dinámica de los sistemas.
Las siguientes herramientas son algunas de las que sirven para ayudar a configurar el
z/OS:
Ayudas del z/OS (z/OS wizards): Ayudantes que se encuentran en la web,
pensados para dar consejos a la hora de parametrizar el sistema, basados en reglas de
uso y prácticas reconocidas.
Configuración del hardware: Hardware Configuration Definition (HCD) es una
parte integrada del sistema operativo. Proporciona una interfaz para configurar el
subsistema de canales y los dispositivos conectados al hardware y al software.
IBM Corporation
21/02/2011
28 de 131
2.7.5
Tecnologías auto-reparadoras
Desde su concepción el z/OS ha incorporado filosofías auto-reparadoras y
características de disponibilidad, fiabilidad y servicio. Los nuevos desarrollos en el z/OS
tratan de mejorar estas características continuamente.
Entre estas técnicas podemos citar la automatización del Sysplex paralelo, basada en el
“IBM Tivoli System Automation for z/OS” que proporciona elementos auto-reparadores
para aplicaciones, sistema y recursos del Sysplex.
También podemos hablar del “IBM Health Checker for z/OS” que ayuda a simplificar y
automatizar la identificación de problemas potenciales de configuración antes de que
afecten a la disponibilidad del sistema o causen una caída. Compara los parámetros y
valores del sistema activo con valores sugeridos por IBM o definidos previamente por la
instalación. Es una herramienta preventiva que se está ejecutando continuamente, y
alerta cuando parámetros y valores críticos varían. Provee al z/OS de capacidades
predictivas.
2.7.6
Tecnologías auto-optimizadoras
Una de las ventajas fundamentales del z/OS es su habilidad para priorizar las cargas
corriendo en el sistema para poder utilizar plenamente los recursos del sistema. El z/OS
dispone de una larga historia en el área de auto-optimización en el manejo de cargas y
virtualización. La virtualización de recursos en el z/OS significa que éstos se pueden
dirigir a dónde quiera que éstos se necesiten, no a dónde estén conectados
físicamente.
El “Workload Manager” y el DFSMS, son productos que proporcionan estas
características de optimización al z/OS, así como el “Intelligent Resource Director”
2.7.7 Tecnologías auto-protectoras.
El aislamiento proporcionado a las aplicaciones por el z/OS es un factor diferenciador
clave. Este aislamiento permite que las aplicaciones corriendo en el mismo sistema no
se dañen unas a otras. El z/OS no es vulnerable a la sobreescritura de los búferes
debido a dicho aislamiento.
“Intrusion Detection Services” es un ejemplo de las nuevas tecnologías que mejoran las
características auto-protectoras del z/OS.
2.7.8
Administración de los sistemas End-to-end
IBM Tivoli System Automation para z/OS (SA z/OS) juega un papel importante en la
automatización end-to-end dentro de la iniciativa de lBM de computación autónoma:
aúna las cuatro caras del automatismo para proporcionar una infraestructura autoadministrada para el z/OS. SA z/OS puede ayudar a los clientes a manejar sistemas de
z/OS aislados o en Sysplex paralelo, reduciendo la frecuencia y duración de los
incidentes que puedan tener un impacto en la disponibilidad del IT.
SA z/OS ayuda a los clientes a simplificar la administración, minimizar los costes y
maximizar la disponibilidad de las aplicaciones. SA z/OS es una solución de alta
disponibilidad para aplicaciones críticas, proporcionando procesos auto-reparadores y
automatización para la E/S, los procesadores y la operación del sistema. Los
administradores del sistema definen el estado ‘deseado’ y el software monitorizará y
aplicará la respuesta apropiada en el sistema si se desvía del estado deseado.
SA z/OS trae más de 40 plug-and-play módulos de políticas de automatización
incluyendo IMS, CICS, Tivoli Workload Scheduler, DB2, mySAP, GDPS y WebSphere.
IBM Corporation
21/02/2011
29 de 131
Estos módulos se basan en las prácticas aconsejadas, experiencias de clientes y el
conocimiento profundo de cada aplicación. Muchas aplicaciones comerciales y
componentes del z/OS proporcionan una administración automática de mensajes ‘lista
para usar’ que requieren un esfuerzo mínimo para su puesta en marcha y ayudan a
conseguir una instalación de primer nivel. Esta poderosa política de mensajes soporta
diferentes tipos de automatización para diferentes tipos de códigos de mensajes.
SA z/OS se puede usar como base para desarrollar una solución automática end-to-end
para la administración de sistemas.
2.7.8.1
El valor del SA z/OS
La automatización en el entorno z/OS es importante hasta el punto de ser casi un
requerimiento.
Una ventaja de SA z/OS es que convierte la automatización del Sysplex paralelo en una
realidad. Maneja cualquier número de sistemas individuales y clusters desde un único
punto de control, dispone de una interfaz amigable basada en Java, que permite
agrupar los recursos, definir las dependencias y los objetivos a un nivel de Sysplex.
Otra ventaja de SA z/OS es que es auto-reparadora de acuerdo con políticas definidas.
Reduce la complejidad, el tiempo de implantación, el código y el esfuerzo requerido
para el mantenimiento a través de políticas de automatización que se pueden compartir
o clonar a lo largo de todo el entorno. El beneficio de esto es que las políticas se
construyen fácilmente usando variables de clonación y predefiniendo normas autoconfigurables de los mensajes. Con AS z/OS se puede monitorizar el sistema a la
búsqueda de señales de daños y aliviar dichas condiciones antes de que el daño pase
a mayores. SA z/OS incluye información sobre rendimiento proporcionada por el IBM
Tivoli OMEGAMON en el marco del proceso de automatización. Este marco permite
informar proactivamente al técnico responsable de problemas con el rendimiento en el
sistema y finalizar Jobs o mover cargas de acuerdo con las acciones apropiadas
definidas en la política antes de que ocurra el daño.
SA z/OS se integra con otros productos de Tivoli incluyendo IBM Tivoli Enterprise
Console y IBM Tivoli Business System Manager para proporcionar un complejo de
automatización tanto para el sistema como para las comunicaciones.
2.7.8.2
Administración de los sistemas a nivel de empresa
IBM Tivoli System Automation for Multiplatforms utiliza un adaptador de infraestructura
para integrarse con SA z/OS, permitiendo automatizar efectivamente aplicaciones
compuestas que se expanden a través de distintos sistemas. Este es un punto único de
alta disponibilidad para z/OS, Linux y IBM AIX. Permite consultar el estado, agregado y
detallado, de los componentes de la aplicación, manejar todos los componentes de la
aplicación con una única interfaz e incrementar la disponibilidad ayudando a resolver
las dependencias cruzadas entre plataformas. SA z/OS en conjunto con SA for
Multiplatforms permite establecer un equipo único para la operación y automatización
de aplicaciones en z/OS, Linux y AIX. Esto simplifica en gran medida la determinación y
resolución de problemas.
IBM Corporation
21/02/2011
30 de 131
3 Arquitectura System z. Plataforma HW
3.1 Conceptos de la arquitectura System z
La arquitectura System z se diseñó, desde su origen, con un concepto clave:
COMPARTIR.
Esto compartir empezó en los componentes HW (primero la CPU, a continuación la
memoria y por último la E/S y la red) y ha terminando compartiendo hasta los datos
usados por los distintos sistemas de la plataforma.
Otra característica importante es la existencia de múltiples procesadores adicionales a
los que figuran como tales.
Cuando se dispone de un procesador de 6 vías que accede a la red IP, que tienen
acceso a dos baterías de discos y a un robot, estamos, no se dispone solo de las 6 vías
del nombre, si no que se dispone de 12 procesadores mas para la E/S, otros dos para
el acceso a la red y 4 o 6 mas para las tareas de cifrado y compresión.
Antes de ver un esquema más general, vamos a describir algunos conceptos clave en
esta arquitectura. Son conceptos con significados diferentes según la arquitectura de
que se trate. Esta ambigüedad puede llevar a error y eso se pretende evitar aquí.
3.1.1 Multiprogramación/Multiproceso/Multithreading
Los primeros sistemas operativos en los predecesores de System z eran mono
programa. Sin embargo muy pronto apareció la necesidad de compartir la CPU entre
más de un usuario y en la actualidad todos los sistemas son multiprograma, es decir
son capaces de ejecutar más de un programa simultáneamente.
Cuando un trabajo no puede usar el procesador por la razón que sea (porque esta
esperando por una operación de E/S asíncrona, por ejemplo) la multiprogramación,
permite suspender el trabajo y liberar, por tanto, el procesador para ejecutar
instrucciones de otro trabajo. Cuando la operación asíncrona de E/S termina, el
segundo trabajo se interrumpe y el primero vuelve a estar listo para usar la CPU.
Los sistemas operativos pueden repartir de este modo la CPU porque capturan y salvan
toda la información de estado del programa que se interrumpe antes de quitarle el
control. De esta manera, son capaces de restaurar al punto exacto de ejecución en que
se quedó.
EL rendimiento de la multiprogramación está muy relacionado con el ‘como’ y el ‘donde’
se salva el estado del programa interrumpido.
El como es con una mezcla de HW/SW llamado PSW Switch que será descrito más
adelante.
El donde es en los distintos niveles de Cache del sistema. Cuanto mas memoria cache
haya y mas próxima esté al procesador, mas posibilidad hay de que los datos de una
ejecución, se restauren con un consumo mínimo de ciclos de CPU.
Cuando una máquina tiene múltiples procesadores, el sistema operativo soporta
multiproceso que es la capacidad de que múltiples procesadores procesen
instrucciones de de varios programas simultáneamente.
IBM Corporation
21/02/2011
31 de 131
Para que esto sea posible, tiene que ocurrir que los procesadores compartan los
distintos recursos HW necesarios, como memoria y disco externo.
El multiproceso permite tanto la multiprogramación (un procesador ejecuta varios
programas simultáneamente), como la ejecución en paralelo (un único programa puede
utilizar distintos procesadores a la vez para hacer trabajo en paralelo).
El entorno System z soporta multiprogramación y multiproceso desde hace muchos
años, prácticamente desde sus orígenes.
La carga típica de un Mainframe es una mezcla de gestores de BBDD (que son tareas
‘long running’) y que actualizan millones de registros mezclado con programas ‘batch’ y
con aplicaciones ‘online’ usadas por miles de usuarios.
3.1.1.1
Multiproceso en z/Architecture
z/Architecture® define que un procesador puede procesar una corriente de
instrucciones, y solo una, en cada instante de tiempo.
z/Architecture está documentada en el manual: ‘Principles of Operation, A22-7832-04.
Este manual define el HW System z incluyendo las instrucciones y los recursos
requeridos para usarlo.
Cuando se añaden mas procesadores a un servidor, cada procesador comparte la
memoria del mismo y procesa su corriente de instrucciones simultáneamente, y de
forma independiente, de los otros procesadores.
Hay instrucciones de z/Architecture diseñadas específicamente para asegurar la
integridad en un entorno multiproceso; estas instrucciones pueden ser usadas por los
sistemas operativos (por ejemplo z/OS) para implementar el mecanismo de ‘locking’
que protege, entre otras cosas, el acceso a ciertos campos de memoria compartida
externa.
Una única instancia del sistema operativo maneja todos los procesadores, y es el
responsable de asignar trabajo a un procesador disponible. Si un procesador falla, el
HW de z10 asignará uno de reserva y el trabajo continuará sin interrupción.
3.1.2 Mecanismo de interrupciones
La multiprogramación en System z está basado en un esquema de interrupciones.
La multiprogramación requiere que exista alguna técnica para cambiar el control de un
programa a otro para que, por ejemplo, cuando el programa A esté esperando a que
una petición de E/S se complete, el programa B pueda ejecutarse.
En el z/OS esto se consigue a través de las interrupciones, que son eventos que alteran
la secuencia en la cual el procesador ejecuta las instrucciones. Cuando ocurre una
interrupción, el sistema salva el estado de la rutina interrumpida y analiza el proceso de
interrupción.
Una interrupción puede ser planificada, es decir solicitada por un programa en
ejecución, o no planificada, es decir causada por un evento que no necesariamente
tiene relación con el programa en ejecución.
Como ejemplo de las planificadas están las que necesitan la ejecución de rutinas
especiales del sistema. Bien para operaciones especiales (llamadas al supervisor o
IBM Corporation
21/02/2011
32 de 131
SVC) o para intentar solucionar o al menos recopilar datos cuando hay algún error.
Estas últimas se llaman interrupciones de programa.
Son no-planificadas, las de E/S que se producen cuando ha terminado una operación
de E/S asíncrona, las de Restart que se produce cuando el operador selecciona la
opción Restart, y las Externas que incluyen diversos eventos externos, como una
llamada desde otra CPU o la expiración de un intervalo de tiempo.
También son no-planificadas las que se producen cuando hay un error de máquina.
A modo de anexo se incluye una descripción de los distintos tipos de interrupciones
El z/OS utiliza los siguientes tipos de interrupciones:
1. Llamadas al supervisor o interrupciones SVC. Estas interrupciones ocurren
cuando el programa lanza una SVC para pedir un determinado servicio del
sistema. Una SVC interrumpe el programa que se está ejecutando y da el
control al supervisor para que pueda realizar el servicio requerido. Los
programas piden estos servicios a través de macros tales como OPEN (abrir
un fichero), GETMAIN (obtener memoria), o WTO (escribir un mensaje al
operador del sistema).
2. Interrupciones de E/S. Estas interrupciones ocurren cuando el subsistema
de canales señala un cambio de estado, tal como la finalización de una
operación de E/S, la ocurrencia de un error, o que un dispositivo de E/S, tal
como una impresora, está listo para empezar a trabajar.
3. Interrupciones externas. Estas interrupciones pueden indicar varios
acontecimientos, tales como la expiración de un intervalo de tiempo, una
interrupción desde la consola, o que el procesador reciba una señal desde
otro procesador.
4. Interrupciones de reinicio (Restart interrupts). Esta interrupción ocurre
cuando el operador selecciona la función ‘RESTART’ en la consola o
cuando la instrucción restart SIGP se recibe desde otro procesador.
5. Interrupciones de programa. Estas interrupciones son causadas por errores
de programa (por ejemplo que el programa intente ejecutar una operación
inválida), ‘page faults’ (el programa referencia una página que no está en la
memoria central), o pide monitorizar un suceso.
6. Interrupciones de error máquina. Estas interrupciones las causa un error
del procesador y su resolución termina en asignación de un procesador de
reserva en sustitución del que ha fallado.
3.1.2.1
Uso de las interrupciones para controlar la secuencia de ejecución
Para identificar y mantener un registro de su trabajo, el z/OS representa cada unidad de
control con un bloque de control. Existen dos tipos de bloques de control: ‘Task control
blocks’ o TCB’s, que representan tareas ejecutándose dentro de los espacios de
direcciones y ‘service request blocks’ o SRB’s que representan servicios de sistema
cuyo ámbito no se restringe a un solo A.S..
Después de que se ejecute la interrupción, el sistema operativo determina qué unidad
de control (de entre todas las presentes en el sistema) está lista para ejecutarse y tiene
la prioridad más alta, entonces le pasa el control.
IBM Corporation
21/02/2011
33 de 131
En la arquitectura System z, y cuando el sistema operativo es z/OS, el control del
procesador esta implementado con el uso de una zona de memoria en la que se indica
la siguiente instrucción a ejecutar y las direcciones donde se encuentran los datos, así
como información de control.
Esta zona de memoria se llama PSW (Program Status Word) y existe una por cada
procesador.
Es un área de 128 bits en la que además de la siguiente instrucción a ejecutar, indica
las condiciones de ejecución, por medio de diversos bits. Indican, por ejemplo si la
secuencia de instrucciones puede ser interrumpida o no o incluso que tipo de
interrupciones se admiten y cuales no.
La siguiente tabla indica los bits más representativos:
6
Habilita las interrupciones de E/S
7
Habilita las interrupciones externas
8-11
Clave de memoria
15
Estado privilegiado o de usuario
31-32
Modo de direccionamiento: 16, 31 o 64 bits
Cada tipo de interrupción tiene una zona de memoria asociada que consta de dos
partes:
La llamada PSW vieja que es donde se guarda el contexto (la PSW) del programa que
se estaba ejecutando cuando la interrupción se produjo.
La llamada PSW nueva que es la que se carga como activa cuando se produce la
interrupción. Esta contiene la dirección y las condiciones de ejecución de la rutina
asociada con la interrupción.
En un sistema de multiprogramación, casi cualquier secuencia de instrucciones puede
ser interrumpida para ejecutarse más tarde. Si dicho conjunto de instrucciones está
manipulando o modificando un recurso (por ejemplo, un bloque de control o un fichero),
el sistema operativo debe impedir que otros programas usen ese recurso hasta que el
programa interrumpido haya completado su proceso sobre dicho recurso.
El z/OS asegura la integridad mediante los métodos de serialización de encolamiento
(GRS) bloqueo (lock) y una tercera técnica llamada latching.
Todos los usuarios pueden usar el encolado pero sólo rutinas autorizadas pueden usar
el bloqueo para la serialización de los recursos.
3.1.3 Virtualización
Como se ha visto en el capítulo anterior, la capacidad de compartir todos los recursos
esta basada en una de las características más importantes y básicas del diseño de
System z. System z es una arquitectura virtual y que nació virtual.
IBM Corporation
21/02/2011
34 de 131
Es un concepto que, en la actualidad, está muy extendido y que se podría definir como
la técnica de esconder las características físicas de los recursos a los usuarios de
dichos recursos.
Por ejemplo, cada sistema operativo ejecutándose en una partición lógica de la
plataforma System z ‘cree’ que tiene acceso exclusivo al HW. La técnica de
virtualización esconde el hecho de que ese HW esta siendo compartido por todas las
particiones lógicas.
Como se ha dicho mas arriba, la virtualización no es un añadido a la plataforma.
z/Architecture contiene facilidades tanto en el HW como en le SW base (sistemas
operativos) que facilitan la compartición de los recursos. Todos los elementos de
System z contienen componentes que facilitan la virtualización.
Virtualizar el entorno System z, implica crear sistemas virtuales (Particiones lógicas y
máquinas virtuales) y asignar recursos virtuales, como memoria, capacidad de proceso,
capacidad de E/S o capacidad de networking a dichos sistemas. .
Los recursos se pueden añadir o quitar dinámicamente a estas particiones lógicas
mediante el uso de comandos de operador.
Aunque se hablará mas adelante, también el HW real se puede añadir en muchos
casos dinámicamente. Tanto CPU como memoria como E/S.
El particionamiento lógico y las máquinas virtuales, incrementan, por tanto, la
flexibilidad al permitir que recursos físicos se añadan o quiten de manera dinámica y no
disruptiva de los sistemas virtuales.(LPAR o Virtual machines) activos y en uso.
El esquema de virtualización de los sistemas actuales, suele corresponder a uno de los
siguientes tipos:
•
Particionamiento HW. El servidor se subdivide en fracciones, cada una de
ellas con su parte de CPU, Memoria y E/S. En cada una de estas fracciones se
ejecutan instancias diferentes del sistema operativo.
•
Hypervisor Bare Metal. Los recursos son propiedad de un SW Hypervisor que
se ejecuta directamente en el HW y que reparte los recursos entre los usuarios
Hypervisor Hosted . Lo mismo que el anterior pero el SW hypervisor necesita
ejecutarse en un SO que es el propietario de los recursos.
Los dos esquemas de virtualización de System z son del segundo tipo.
En la figura se describen las capacidades de virtualización de System z
IBM Corporation
21/02/2011
35 de 131
3.1.4 Otras características importantes del HW
Para finalizar esta sección algunas peculiaridades más:
•
Registros. Son zonas de memoria especiales con misiones específicas. Una de
sus misiones es contener las direcciones de memoria virtual, tanto las de las
operaciones como las de los datos.
•
Instrucciones. Son el conjunto de instrucciones que el microcódigo de System
z suministra. Son las que usa tanto los S.O como el middleware. Están
publicadas en el manual ‘Principles of Operation’. Este juego se va ampliando de
manera integrada con las modificaciones en el HW. Esta es la razón de que exista una
sinergia tan grande en System z entre el HW y el SW base. Las mejoras en el HW de z10
fueron acompañadas por la inclusión de 50 instrucciones más en el juego de
instrucciones.
•
Direccionamiento de 24, 31 y 64 bits. System z soporta el direccionamiento en los 3
modos de modo que al mismo tiempo que sirve aplicaciones con grandes necesidades de
memoria (64 bits) permite seguir ejecutando sin inversión adicional programas escritos
para 24 bits sin modificación ni migración. Este último hecho forma parte del
compromiso de protección de la inversión en System z
3.2 Componentes y sus características
System z como todos los sistemas esta construido a partir de componentes HW. La
mayoría de estas componentes se incluyeron en el diseño inicial en los años 60/70 y se
han ido mejorando y desarrollando a lo largo de los años .
La siguiente figura es un diagrama esquemático de estas componentes
3.2.1 Z10
El modelo de HW actual es el 2097 y se fabrican 2 modelos: z10 EC de 1 a 64
procesadores y el z10 BC de 1 a 10 procesadores.
3.2.1.1
System z frames and cages
Jaula o ‘cage’ es la estructura en la que se insertan los distintos componentes. Hay dos
tipos:
1. CEC cage: Contiene las processor units (PU), la memoria física y conectores a
las otras jaulas.
2. I/O cage: Contiene las tarjetas de canal que conectan con los dispositivos
externos.
Los sistemas se componen de una jaula tipo CEC y de 1 a 3 jaulas de E/S.
3.2.1.2
System z book.
El concepto de book viene de la generación n-3. Un book contiene procesadores,
memoria y la conexión a la ‘jaula’ E/S.
Los books están insertados en la jaula del CEC. Cada System z contiene de 1 a 4
books, y cada uno contiene:
IBM Corporation
21/02/2011
36 de 131
16 unidades de proceso (PU). De estas se emplean algunas para dedicarlas a
las operaciones de E/S y siempre existe algún procesador de reserva (spare).
Por eso aunque, teóricamente, la capacidad máxima es de 64 procesadores, el
modelo mayor dispone de 54 procesadores, ya que el resto se dedican a
funciones de reserva y de E/S.
16 a 128 GB de memoria física
Hasta ocho ‘memory bus adapters’ que son los responsables de la conectividad
a la jaula de la E/S.
En la figura se ve un book de z10
3.2.2 Procesadores
La unida de proceso (processing unit (PU)) es el corazón de cualquier HW. La
plataforma System z tiene una unidad de proceso única con su propio conjunto de
instrucciones
Las unidades de proceso están basadas en un chip de cuatro PUs organizadas de
acuerdo al siguiente esquema:
Estos procesadores son ayudados por otros dos (COP en la figura) que están
especializados en servicios de compresión y cifrado.
La función de cifrado se llama CP Assist for Cryptographic Function (CPACF) y permite:
• Cifrar y descifrar con protocolos DES/TDES/AES. El resto de
protocolos utilizan la tarjeta Crypto Express de la que se hablará mas
adelante.
• Algoritmos de generación de MAC, hashing seguro y generación de
números Pseudo Random.
IBM Corporation
21/02/2011
37 de 131
Hay diferentes tipos de Pus, aunque todas ellas usan el mismo chip. Se caracterizan
como distintos tipos dependiendo del uso.
Si un proceso está sin caracterizar, esta como disponible. Si ocurre un fallo de HW en
cualquier tipo de procesador, el sistema caracteriza uno de los disponibles con el
mismo tipo y lo sustituye.
En z10, existen los siguientes tipos de procesador:
•
Central processor (CP). Este es el procesador básico y en el se ejecutan los
Sistemas Operativos y las aplicaciones. Si existe algún procesador de otro tipo,
parte de ese trabajo se descargará.
•
Integrated Facility for Linux (IFL). Es un CP en el que solo se ejecuta Linux o
z/VM con guest Linux. Este tipo de procesador no se tiene en cuenta para el
cálculo del coste SW.
•
System z Application Assist Processor (zAAP). Los zAAP los usa la IBM Java
Virtual Machine (JVM™) para ejecutar código JAVA. Lo mismo que con los
IFLs, lo que se ejecute en zAAP no contribuye al coste de SW.
•
System z Integrated Information Processor (zIIP). Los zIIP están pensados,
principalmente, para descargar parte del proceso de acceso a los datos (DB2),
aunque no es el único. También ejecuta código de cifrado, XML, etc.
Igualmente, lo ejecutado en zIIP no contribuye al cálculo del coste HW.
•
Integrated Coupling Facility (ICF). Estos procesadores solo ejecutan un código
especial : Coupling Facility Control Code (CFCC). Es el código de control de la
memoria externa en la que esta basado el clustering (que en System z se llama
SYSPLEX)
Spare Es una PU sin caracterizar y disponible para, en caso de error en cualquiera de
los otros, sustituir al procesador que falla adquiriendo su caracterización. Forma parte
del diseño N+1.
Procesador SAP. En cada máquina System z existe, al menos, un procesador SAP.
Este no esta disponible para los Sistemas operativos aunque está en los mismos Chips
que el resto. Este procesador ejecuta un código interno que es parte del subsistema de
E/S del servidor. Esto descarga de los procesadores centrales el trabajo de
comunicación con los canales, dejando disponibles los mismos para la ejecución de las
aplicaciones.
La unidad de instalación en el z10 es el book. Del total de Pus (entre 17 y 20) se
activan las contratadas, pero el resto están. Eso hace que se pueda añadir potencia de
forma dinámica.
Ante un pico de demanda, ante la necesidad de absorber la carga de otra máquina bien
por parada planificada o por error, es necesario a veces poder disponer de memoria
adicional sin depender del suministrador.
En z10, existen varias opciones de Capacity On Demand que permiten dicha
flexibilidad.
3.2.3
3.2.3.1
Memoria
Memoria Central
Los sistemas z utilizan módulos DIMM (Dual In line Memory Module) de 4 GB u 8 GB.
La suma total disponible por book es de 384 GB lo que da, en los modelos actuales, un
total por máquina de 1,5 TB.
IBM Corporation
21/02/2011
38 de 131
Esta memoria se reparte entre las particiones, aunque algunos sistemas operativos
como el z/OS permiten reservar memoria para ser asignada a otra partición en caso de
necesidad.
También la memoria se instala en módulos completos permitiendo la posibilidad de
añadir memoria de forma dinámica, activando la que ya se encuentra instalada.
3.2.3.2
Memoria Cache
Además de la memoria central, existen una serie de niveles de cache que permite un
mayor rendimiento en el acceso de las Pus a los datos.
Cuanto mas cerca estén los datos de las unidades de proceso, menos ciclos de
máquina se desperdiciarán a la espera del dato y, por tanto, mayor será el rendimiento
global.
En las máquinas z10 existen varios niveles de Cache:
Asociados a la PU
Nivel 1.
64K para instrucciones y 128K para datos
Nivel 1.5
3MB
Asociados al Book y compartidas entre las Pus que contiene
Nivel 2
3.2.3.3
2 Cache de 24 MB cada una. En total 48 MB
Memoria Compartida (Coupling Facility)
Procesador especializado y memoria dedicada para compartir la información entre las
imágenes de un Sysplex.
3.2.4 E/S
3.2.4.1
Subsistema de canales
Una de las mayores fortalezas de los Mainframe es su capacidad para manejar un gran
número de operaciones de E/S simultáneas.
Esta capacidad proviene en gran parte de la existencia de un subsistema especializado
así como del uso de procesadores específicos (SAP y canales)
Como se ha dicho mas arriba, esto permite simultanear la ejecución de las aplicaciones
con el proceso de la E/S.
El subsistema de canales o CSS (channel subsystem ) maneja el flujo entre los
dispositivos de E/S y la memoria.
SAP usa la configuración de E/S para saber encaminar la petición por el canal
correspondiente al dispositivo de destino.
Los canales controlan la transmisión del dato entre la memoria y el dispositivo. Suelen
ser compartidos entre todas las particiones que existen en un sistema.
IBM Corporation
21/02/2011
39 de 131
Hay canales de varios tipos:
•
Acceso a almacenamiento externo (SAN)
o
Canales ESCON. Son los mas antiguos y se mantienen por
compatibilidad con dispositivos antiguos. Usan conexiones de fibra y el
protocolo de transmisión es de tipo Full dúplex.
o
Canales FICON. Existen de distintas velocidades (en la actualidad con
un máximo de 8 GB/S). La gran mayoría de los dispositivos tienen
adaptadores para este tipo de canal y se pueden configurar de dos
maneras:
Como canales FICON para los dispositivos que manejen z/OS y
z/VM.
•
Como dispositivos FCP para dispositivos con Adaptadores SCSI.
Esto permite a los usuarios de Linux, acceder a ambos mundos.
A dispositivos FICON virtualizados por el z/VM o a dispositivos
SCSI directamente o bajo z/VM
Acceso a la Red Ethernet
•
Canales OSA. La tarjeta OSA (Open System Adapter) conecta el
System z con la red Ethernet. Es usada principalmente por el TCP/IP y
además de proveer la conexión con el mundo exterior, descarga al
TCP/IP de ciertas funciones, como por ejemplo la segmentación de
mensajes.
Comunicación con la Memoria externa (Coupling Facility)
o
Son canales que se manejan con distintos protocolos y que conectan los sistemas a la
memoria externa. Hay de varios tipos dependiendo de la conectividad y del protocolo
usado.
3.2.4.2
o
ICB (Integrated Cluster Bus) La conexión es de cobre y tiene, por tanto
limitación de distancia. Es el que da mas velocidad y mas ancho de
banda
o
ISC (Inter System Coupling). La conexión es de fibra y se propaga a
más distancia. No obstante su ancho de banda y su velocidad son
menores.
o
IFB Infiniband. En la última versión se ha empezado a utilizar el
estándar Infiniband para la conexión a la memoria externa. La conexión
es de fibra como en ISC, pero el protocolo es distinto.
Control units y dispositivos
Los dispositivos de almacenamiento que se acceden desde System z pueden ser, tanto
los tradicionalmente soportado por el Sistema operativo z/OS y con protocolo exclusivo,
como los accedidos desde Linux en z que se acceden con protocolos mas estándar.
En su origen, los dispositivos disponibles para el predecesor de z/OS necesitaban una
unidad de control especializada en su manejo. Además los dispositivos de acceso
directo (o discos) tenían una tecnología de discos accedidos en paralelo que formaban
pistas y cilindros.
IBM Corporation
21/02/2011
40 de 131
Aunque el z/OS sigue trabajando con pistas y cilindros, en la actualidad el z/OS soporta
loas llamados EAV (Extended Adres Volumes) que permiten acceder sin las
limitaciones de la antigua tecnología a los datos residentes en la nueva.
Al mismo tiempo, y fiel a su política de ‘backward compatibility’, se pueden seguir
ejecutando los programas antiguos que siguen creyendo que sus datos residen en los
antiguos dispositivos.
3.2.5 Time-of-Day clock
Cuando hay proceso cooperativo de varios sistemas (como ocurre en la mayor parte de
las instalaciones System z) es importante que todos ellos tengan sincronizados sus
relojes internos con un alto nivel de precisión, ya que los tiempos que se manejan están
entre los nanosegundos y los microsegundos.
STP (Server Time Protocol) es una facilidad que se incluye en el microcódigo para la
sincronización de tiempos.
Es una versión para System z del protocolo NTP que está ampliamente difundido.
La comunicación entre sistemas se hace utilizando las conexiones con la memoria
externa o CF(Coupling Facility), ya que la existencia de la CF es condición
imprescindible para el proceso cooperativo.
Para las aplicaciones multiplataforma que necesitan coordinación de tiempos con el
resto de servidores, el STP puede actuar tanto como servidor (dando la hora al resto de
servidores) como siendo cliente(y tomando la hora del servidor de tiempos que se
defina).
3.2.6 CP Assist for Cryptographic
En System z las capacidades de seguridad están integradas en el HW. Además de las
tarjetas criptográficas, existen coprocesadores especializados en el cifrado que forman
parte del chip en que residen las Pus.
Estos procesadores son llamados “CP Assist for Cryptographic”
3.2.7 HiperSockets
Se llama HiperSockets a la tecnología que provee conexión TCP/IP de gran velocidad
entre servidores de distintas LPAR de la misma máquina. La comunicación se
establece utilizando la memoria de la máquina, con lo que se evita la salida al exterior y
se ahorra, por tanto, la latencia de la red.
3.2.8 Hardware Management Console (HMC)
El HW System z se puede manejar desde el Support Element (un Thinkpad conectado
directamente al chasis y al que se accede abriendo la puerta del 2097, o desde la
Hardware Management Console (HMC), que es una aplicación Desktop basada en linux
que suministra la Interfaz de usuario para controlar y monitorizar el estado del sistema.
Trabajando desde la HMC, los operadores, los técnicos de sistemas o el personal
técnico de IBM pueden efectuar las operaciones básicas en los servidores System z.
Las operaciones más comunes son:
Cargar la configuración HW
Cargar o restaurar un sistema (z/VM, z/OS, …)
Cambiar la configuración de las LPAR.
IBM Corporation
21/02/2011
41 de 131
Modificar el HW(añadir o quitar CPs, canales, etc.). La mayor parte de estas
modificaciones son dinámicas.
Acceder a los Logs de HW
Comprobar el uso de los CPs y los Canales.
Comprobar el consumo de energía
La HMC esta conectada al servidor(es) a través de una red IP privada.
Aunque habitualmente existen 2 HMCs por redundancia, desde una sola HMC se puede
controlar todo el HW que exista en la red. Todos los servidores y las particiones lógicas
definidas en los mismos así como toda la E/S asociada.
3.2.9 Detalles de virtualización del HW
3.2.9.1
PR/SM y Particiones Lógicas (LPAR)
Procesor Resource/Systems Manager™ (PR/SM™) es un hypervisor integrado con
todas las componentes de System z que mapea los recursos físicos en lógicos para que
las distintas LPARs los puedan utilizar de manera simultanea .
Esta componente permite agregar recursos de un tipo (por ejemplo CPs) en ‘pooles’
desde los que los usuarios virtuales reciben los recursos virtuales.
Esta es una característica muy importante y crucial para permitir una consolidación de
cargas que permita un uso más efectivo de recursos. Es decir que aumente el
porcentaje de ocupación de los recursos manteniendo el rendimiento.
PR/SM permite el particionamiento lógico del z10 en diversos z10 virtuales
denominados LPARs (Logical PARtition).
EL PR/SM mantiene el aislamiento entre las diversas LPAR, lo que permite usar las
LPAR como si fueran máquinas separadas. Tanto desde el punto de vista de la
integridad de datos y procesos como desde el punto de vista de la seguridad lógica, Los
estándares de seguridad EAL han dado la ‘calificación’ de EAL5 al particionamiento
lógico.
Cada LPAR (hasta 60 en el z10) ejecuta su propio sistema operativo (cualquiera de los
que soporta el HW: z/VM®, z/OS, Linux on IBM System z, z/TPF, z/VSE)
PR/SM virtualiza los procesadores y la E/S, mientras que la memoria es virtualizada
por los sistemas operativos.
Gestión de la CPU por el PR/SM
Cada partición lógica (LPAR) es definida con un peso. Este peso determina el
porcentaje de la máquina que se le asegura en caso de que, con cargas altas, haya
más de una LPAR compitiendo por el uso de los procesadores.
Este peso es siempre un mínimo aunque en caso necesario puede ser también un
máximo si establecemos la condición de ‘capped’ para esta partición.
Estos pesos son fijos y el operador los puede cambiar de forma dinámica.
Si se necesita que la distribución de estos pesos vaya variando con el tiempo y
ajustándose a los SLAs de las cargas, se puede utilizar el IRD (Intelligent Resource
Director)
IBM Corporation
21/02/2011
42 de 131
Este, extiende el control de la gestión de cargas por objetivos de rendimiento en una
LPAR (WLM) al control de los pesos de las particiones así como del nivel de
multiprogramación requerido (número máximo de procesadores lógicos)
El IRD es también capaz de gestionar la prioridad en la E/S
objetivos de rendimiento.
3.2.9.2
para conseguir los
Virtualización de E/S
La virtualización de E/S permite a las LPARs compartir los mismos canales de acceso
al exterior.
De esta manera las distintas particiones pueden acceder de manera concurrente tanto
al almacenamiento (discos y cartuchos) como a la red.
La virtualización hace que cada LPAR crea que tiene uso exclusivo y es el microcódigo
quien se encarga de ordenar dicho acceso.
La componente del microcódigo dedicada a esta virtualización se llama EMIF.
3.2.10 Hiperdispatch
Es una función que permite mejorar el rendimiento aumentando las posibilidades de
que el dato que necesita una instrucción se encuentre en la memoria cache más
próxima.
El Hiperdispatch tiene dos componentes, una HW (o microcódigo del PR/SM) y otra SW
(en el dispatcher del z/OS).
La primera aplantilla una CPU lógica sobre una física utilizando un algoritmo que busca
la reutilización del primer nivel de cache. Es decir siempre busca aplantillar la CPU
lógica sobre la última física en la que se ejecutó. En caso de que no esté disponible,
aplantilla sobre otra. En ningún caso hace esperar por esta causa.
Esta es la componente HW.
La componente SW (el dispatcher o repartidor de la CPU) divide los procesadores
lógicos en grupos de cuatro y asocia a cada grupo un conjunto de tareas.
De esta manera cada tarea tiene mas probabilidades de ejecutarse en la misma CPU
lógica, que a su vez se procura aplantillar sobre la misma física, de manera que los
datos que había referentes a la tarea en los distintos niveles de cache están aún ahí, y
no han sido sustituidos por otros.
IBM Corporation
21/02/2011
43 de 131
4 Arquitectura System z. Plataforma SW- SW
Base
Podemos clasificar los componentes software que se requieren dentro del entorno z/OS
en los siguientes bloques funcionales:
Sistema Operativo (IBM z/OS) y componentes
“Middleware” (gestor de colas ,gestor transaccional, gestor de BBDD)
gestión de sistema
En este capítulo nos centraremos en el primer punto y el capitulo siguiente, cubrirá el
resto
4.1 IBM z/OS y componentes
El sistema operativo z/OS, “buque insignia” del Mainframe de IBM, está diseñado para
proporcionar las más altas calidades de servicio para los datos y transacciones de las
empresas y extiende estas calidades a las nuevas aplicaciones utilizando las últimas
tecnologías de software.
Ofrece una base altamente segura, escalable y de alto rendimiento en la que implantar
aplicaciones habilitadas para SOA utilizando tanto tecnologías altamente implantadas y
estables tipo OLTP, como tecnologías Internet y Java™, proporcionando un completo y
diverso entorno de ejecución, así como un almacén de datos de empresa altamente
seguro y flexible.
Las excelentes características y solidez de este sistema operativo, abarcan un amplio
número de categorías:
Modelo de proceso centralizado.
Seguridad.
Gestión.
Virtualización y gestión de las cargas de trabajo.
Fiabilidad.
Escalabilidad.
Disponibilidad.
Comunicaciones y I/O.
Procesos transaccionales.
Procesos batch.
El IBM System z/OS consigue sus calidades de servicio (QoS) en la combinación del
hardware del IBM System z y de las capacidades del Parallel Sysplex. Para
proporcionar estas características, el IBM System z/OS incluye un amplio conjunto de
capacidades y herramientas.
z/OS es el Sistema Operativo mas característico de System z y su desarrollo ha ido
para lelo al del HW. Por eso es el que mejor explota todas las capacidades del mismo.
Se encarga de repartir los recursos de que dispone, procesador y memoria, entro las
distintas unidades de trabajo lo necesitan
Aunque nació como un sistema operativo para dirigir la ejecución de un único trabajo,
rápidamente se convirtió en un sistema operativo que es capaz de manejar muchos
miles de programas y usuarios concurrentemente.
IBM Corporation
21/02/2011
44 de 131
Desde sus inicios el diseño de z/OS tiene como objetivo primordial alcanzar el la
máxima calidad de servicio posible utilizando la tecnología disponible en cada
momento.
Esta calidad de servicio forma parte intrínseca del sistema, y por lo tanto es aplicable
tanto a las transacciones operativas que utilizan Middleware tradicional como a las
nuevas aplicaciones que utilizan las últimas tecnologías software.
Es, por ejemplo, una plataforma escalable y segura en la que desplegar aplicaciones
SOA usando tecnología JAVA o adaptando la tecnología tradicional.
El diseño de z/OS, está basado en la distintos componentes que trabajan de modo
cooperativo para llevar a cabo las tareas del sistema. A continuación se describen los
más importantes
4.1.1 Gestión de la Memoria
En la gestión de memoria, hay algunos conceptos importantes:
• Address Space (A.S.)
Es el rango de direcciones que el sistema asigna a una unidad de trabajo.
En estas direcciones es donde se almacenan las instrucciones y datos a ejecutar.
Una unidad de trabajo, puede ser un usuario, un programa, un subsistema, etc…
Su tamaño lo da el esquema de direccionamiento. En la actualidad el direccionamiento
es de 64 bits y por lo tanto el máximo tamaño de un A.S. es de 16 hexabytes.
Normalmente se utiliza solo una parte del mismo.
Estas direcciones virtuales se hacen corresponder con direcciones reales por medio de
unas tablas de páginas. Las páginas en z/OS son de 4 K o de 1MB.
Una unidad de trabajo ejecutándose en un AS, no puede ver la memoria de otra unidad
de trabajo.
Este hecho es muy importante para el la fiabilidad final, ya que impide que un error en
una unidad de trabajo arrastre a otras. De la misma forma facilita la recuperación.
Dentro de cada AS hay una zona compartida por todos que se usa como memoria de
comunicación y donde residen los módulos del sistema, o, en general, todos los que
tienen un uso común.
Hay por tanto tres tipos de memoria:
Memoria virtual, que no es más que un rango de direcciones
Memoria real, que es donde se ejecutan las instrucciones y residen los datos que estas
necesitan
Memoria auxiliar. Son ficheros donde se almacenan el contenido de la memoria real
cuando se necesita para otra unidad de trabajo.
IBM Corporation
21/02/2011
45 de 131
Utilizando un esquema LRU (Least Recently Used) el sistema va enviando a memoria
auxiliar el contenido de las páginas de memoria real que hace más tiempo que no se
referencian.
El objetivo es tener siempre disponibles páginas de memoria real donde poder volver a
cargar los datos necesarios para los programas en ejecución.
Esta paginación es, por supuesto, totalmente transparente al usuario.
4.1.2 Gestión y reparto del Procesador- Workload Manager (WLM) .
Una de las fortalezas de la plataforma System z y sus sistemas operativos, es la
capacidad de correr múltiples tipos de carga a la vez, y manejar las prioridades relativas
de dichas cargas.
La función que hace esto posible, es el WLM (WorkLoad Manager)
La idea es poder especificar objetivos de rendimiento para los distintos trabajos en
términos de negocio ( por ejemplo percentil de transacciones con tiempo de respuesta
en bornas de CPU menor de 1 segundo) y hacer que el WLM utilizando unas
construcciones técnicas (reglas de asociación, prioridades de ejecución arranque
automático de servidores, etc…) entendibles por el sistema operativo.
La definición de los tipos de carga y las reglas para manejarlos, es lo que constituye
una política del WLM.
A cada tipo de carga se le asigna un objetivo y una importancia. El objetivo, define
como se espera que se comporte este tipo de carga o el compromiso adquirido con
otros (Service Level Agreement o SLAs). El WLM usa estas definiciones de objetivos
para manejar el trabajo. La política es compartida por todos los sistemas que trabajen
de forma cooperativa (Sysplex)
WLM tiene dos métodos para cumplir los objetivos marcados:
• Repartir recursos del sistema (procesadores memoria e I/O) ajustando las
prioridades.
• Controlar el encaminamiento de la carga a los distintos servidores de
aplicaciones disponibles o, incluso, arrancar servidores nuevos en caso
necesario.
La identificación de la carga la llevan a cabo de manera conjunta el middleware y el
sistema operativo.
Los distintos Middleware (CICS, IMS, WAS, SAP, etc…) informan al WLM cuando entra
al sistema una unidad de trabajo. Esta unidad de trabajo, llega con un conjunto de
características (nombre de la transacción, nombre del servidor origen, dirección origen,
etc..) que permiten al WLM asignarle (siguiendo el conjunto de reglas previamente
definidas) una clase de servicio.
Una clase de servicio representa el objetivo de rendimiento de un tipo concreto de
carga, así como su importancia relativa. Como hemos visto antes, el WLM gestiona y
distribuye los recursos del sistema para intentar cumplir esos objetivos.
IBM Corporation
21/02/2011
46 de 131
Los tipos de objetivos pueden ser:
De tiempo de respuesta.- Estos se usan principalmente para trabajo de tipo
transaccional y se puede especificar, bien la media (es decir el objetivo es que la media
del tiempo de respuesta de las transacciones XXXX sea menor que 0,2 segundos) o
bien el percentil si esperamos una dispersión en los tiempos de respuesta que hagan
poco significativas las medias (es decir el objetivo es que el 95% de las transacciones
XXXX tengan un tiempo de respuesta menor que 0,2 segundos). WLM monitoriza los
tiempos de respuesta de las transacciones y va ajustando la utilización de recursos
para ir consiguiendo los objetivos.
De velocity.- Cuando el tipo de trabajo no tiene asociado un tiempo de respuesta
claramente medible, WLM proporciona otro tipo de objetivo. En este se pretende indicar
como de ‘deprisa’ tiene que ser servido.
Para ello WLM utiliza un mecanismo de muestreo que le permite detectar cuando una
tarea esta retrasada por un recurso (es decir ha pedido el recurso y no lo ha obtenido)
Con estas muestras obtiene un índice llamado ‘velocity’ que es el que se asocia como
objetivo. Las tareas ‘long running’ son apropiadas para este tipo de objetivo.
Ciertos gestores de transacciones pueden crear un tipo de trabajo llamado enclave.
Lo mismo que otras unidades de trabajo, a este se le asigna una clase de servicio
siguiendo las reglas de clasificación.
Los enclaves tienen la característica especial de que la unidad de trabajo que
representan se puede ejecutar en múltiples espacios de direcciones,
IBM Corporation
21/02/2011
47 de 131
4.1.3 Resource Recovery Services (RRS).
Una transacción puede acceder a múltiples BBDD y obtener servicio de múltiples regiones
servidoras y tiene que tener, en caso de error, la capacidad de deshacer todo lo hecho
(back-out).
Si una transacción solo modifica en una BBDD gestionada por un único gestor, la
recuperación la hace el gestor de BBDD sin necesidad de coordinación.
Sin embargo, si una transacción escribe en una ,o mas, bases de datos y/o también en un
fichero secuencial o, incluso, en una Base de datos jerárquica, la recuperación que harán
los distintos gestores, debe ser coordinada desde un único punto
Este punto único de gestión, es un componente llamado RRS.
Los gestores de transacciones, pueden llamar al RRS para coordinar la recuperación en
caso de fallo o pueden utilizar sus propios mecanismos de recuperación en caso que no
haya más que un componente involucrado.
.
RRS proporciona un gestor de puntos de sincronismo (syncpoint) que cualquiera que lo
necesite puede explotar.
4.1.4 Gestión de los datos DFP(Data Facility Program)
DFP es la parte del z/OS que se encarga del acceso a los datos. Su principal
componente es una conjunto de métodos de acceso.
Un método de acceso define la técnica usada para almacenar y recuperar datos. Los
métodos de acceso tienen sus propias estructuras de ficheros para organizar los datos,
sus programas proporcionados con el sistema (macros) para definir los ficheros, así
como programas de utilidad para procesar estos.
Los métodos de acceso, forman parte de la filosofía general del z/OS de liberar a los
programadores de aplicación de la codificación de todo lo que no sean procesos de
negocio. Además su utilización permite optimizar el acceso a los datos.
Los métodos de acceso se identifican en primera instancia por la organización de los
ficheros. Los usuarios de z/OS, por ejemplo, usan el Basic Sequential Access Method
(BSAM) o el Queued sequential access method (QSAM) para ficheros secuenciales.
Hay veces que un método de acceso identificado con una organización se puede usar
para procesar un fichero organizado de manera diferente. Por ejemplo, un fichero
secuencial creado usando BSAM puede procesarse por un BDAM (basic direct access
method), o viceversa. Otro ejemplo son los ficheros UNIX, que se pueden procesar
usando BSAM, QSAM, BPAM (basic particioned access method), o VSAM (virtual
storage access method); Estos últimos son los mas utilizados en la actualidad.
Aunque el uso de los Bases de Datos está totalmente generalizado desde hace mucho
tiempo, aún existen muchas instalaciones que siguen teniendo aplicaciones en
producción con sus datos gestionados en VSAM.
Como ya se ha citado anteriormente, el término VSAM aplica tanto al tipo de fichero
como al método de acceso que se usa para gestionar los diferentes tipos de datos.
Como método de acceso, VSAM proporciona funciones más complejas que otros
métodos de acceso de disco.
Se usa principalmente para guardar datos de las aplicaciones. Para guardar programas
fuente, JCLs o módulos de carga se utilizan los ficheros particionados o librerías.
IBM Corporation
21/02/2011
48 de 131
Hay elementos de middleware del z/OS que internamente guardan también sus datos
en ficheros VSAM, como es el caso de DB2, o los ficheros zFS de los servicios UNIX
Se puede usar el VSAM para organizar los registros en cuatro tipos diferentes de
ficheros, secuenciados por clave (key-sequenced), secuenciados por entrada (entrysequenced), lineales (linear) y de registro relativo (relative record). La diferencia
principal entre ellos es la forma en la que se almacenan y acceden sus registros.
Veamos una breve descripción de los mismos:
•
Key Sequence Data Set (KSDS) – cada registro tiene uno o más campos de
clave y un registro se lee (o inserta) por valor de la clave. Esto proporciona
acceso al azar a los datos. Los registros son de longitud variable.
•
Entry Sequence Data Set (ESDS) – esta tipo de VSAM guarda los registros en
secuencia. Los registros de acceden secuencialmente. Lo usa el IMS, el DB2 y
los USS del z/OS.
•
Relative Record Data Set (RRDS) – permite la lectura de los registros por
número, registro 1, registro 2, … Proporciona un acceso al azar y asume que la
aplicación tiene forma de derivar los números de registro que quiere obtener.
•
Linear Data Set (LDS) – Esto es, en efecto, un fichero byte-stream y es el único
de este tipo en el entorno z/OS tradicional (no-USS). Hay un número alto de
funciones del sistema z/OS que usan este formato ampliamente, pero es raro
que lo usen programas de aplicación.
4.1.5 Gestión del Almacenamiento
La gestión de los datos, consiste en la asignación de espacio, ubicación del mismo,
monitorización, migración, backup, recall, recuperación y borrado de ficheros.
Estas actividades se pueden llevar a cabo o manualmente o usando procesos
automatizados. Cuando se usa este segundo método (lo mas normal) es el sistema
quien se encarga de toda la gestión.
Todas las características de ubicación, migración, backup y borrado se establecen
mediante un conjunto de reglas basadas en distintas características del fichero como el
nombre, el entorno en que se crea, el tamaño, el usuario que lo pide, etc….
De esta manera y de manera automática a cada tipo de dato se le da el tratamiento que
requiere. Un ejemplo sería:
o
El que hace tiempo que no se usa se migra a cartucho de manera
transparente
o
Los datos críticos tienen backup diario y se guardan diez versiones.
o
Los muy críticos tienen copia instantánea (Flash Copy ) cada cierto
tiempo.
Lo que llamamos DFSMS (Data Facility Storage Management Subsystem) es un
conjunto de productos de software que administra automáticamente los datos, desde su
creación a su expiración. El DFSMS proporciona controles para la ubicación de los
datos de acuerdo con la disponibilidad y el rendimiento, servicios de backup/recuperación y recuperación ante el desastre, administración del espacio en disco,
administración de los medios magnéticos e informes y simulaciones para afinar el
rendimiento y la configuración.
IBM Corporation
21/02/2011
49 de 131
Proporciona una solución integrada y comprensiva para la administración de datos.
Facilita una administración del almacenamiento de acuerdo con los SLA’s definidos.
Se puede conseguir hasta un 50% de incremento en la capacidad efectiva del
almacenamiento. Esto redunda en la reducción de costes en el almacenamiento.
Componentes:
•
DFSMSdfp: como se ha descrito en el epígrafe anterior, proporciona funciones
básicas de almacenamiento de datos, programas y dispositivos y algunas
funciones de copia.
•
DFSMSdss: con funciones para el movimiento de datos, copia, back-up y
administración de espacio.
•
DFSMShsm: administra y automatiza las funciones de back-up, recuperación,
migración (archivado) y limpieza del espacio desaprovechado.
•
DFSMSrmm: proporciona funciones administrativas para los recursos
removibles, tales como librerías, cartuchos, y volúmenes lógicos y virtuales.
•
DFSMStvm: es un componente con cargo que permite que transacciones CICS
y trabajos BATCH accedan a ficheros VSAM concurrentemente.
•
DFSORT: producto separado y complementario que proporciona funciones de
ordenado, mezcla, copia, informes y análisis de datos con un alto grado de
rendimiento.
4.1.6 Gestión de los bloqueos -Global resource serialization (GRS)
Como se ha dicho en el capítulo 2, la serialización es clave en System z para permitir
tanto el uso compartido de recursos como la multiprogramación. 3.3.6 Global resource
La serialización de recursos es la técnica usada para coordinar los recursos que usa
más de una aplicación. Los programas que cambian algo, necesitan un control
exclusivo del recurso, en caso contrario el recurso se podría corromper.. Esta
protección se suele llamar integridad de escritura.
Por otro lado, los programas que solo necesitan leer pueden acceder al recurso sin
problemas de integridad..
GRS es la componente de z/OS que gestiona esta serialización por encolamiento tanto
en una única imagen z/OS como entre varias formando un Sysplex.
Serializa los recursos de manera que si hay un usuario con acceso compartido (de
lectura si es un dato) no permite el acceso a ningún usuario que lo necesite exclusivo.
De la misma manera garantiza que si hay un usuario con acceso exclusivo (de escritura
si es un dato) ningún otro puede acceder.
4.1.6.1 Encolamientos (ENQ)
Cuando un programa necesita el acceso al recurso, es su responsabilidad pedir acceso
ordenado a él. Dependiendo del uso que prevea darle, pedirá un uso exclusive o
compartido.
Esto se hace a través de llamadas al sistema en Assembler ENQ/DEQ.
1. El programa pide la utilización de un recurso con una petición de ENQ seguida
de un nombre. Este nombre representa un recurso de cualquier tipo, desde un
fichero a una zona de memoria a la utilización de un programa, etc…
IBM Corporation
21/02/2011
50 de 131
2. Si el recurso no esta disponible, el propio GRS lo pone en estado suspendido o
en espera. De esta situación le saca el GRS en el momento en que el recurso
por el que estaba esperando queda libre.
3. El recurso se queda libre cuando el programa que lo estaba utilizando no lo
necesita mas y hace DEQ del mismo
Aunque los programas escritos por un usuario pueden utilizar estas interfases, son
usadas principalmente por las componentes del sistema para poder utilizar de forma
segura los ficheros y demás recursos.
El ámbito del GRS puede ser Local si las colas se refieren a peticionarios dentro de
una única imagen de z/OS o Global si en las colas de GRS hay peticionarios de los
sistemas de un Sysplex. En este último caso, y para permitir el acceso a todos los
sistemas al mismo dato, las colas residen en la memoria externa del Sysplex o CF
(Coupling Facility).
4.1.6.2
Bloqueos
El uso de bloqueos (o locking) es una forma rápida de serializar el uso de recursos de
sistema por parte de rutina específicas.
Un ‘lock’ es una zona de memoria que indica si un recurso está siendo usado y quién lo
usa.
Este procedimiento lo usan la mayor parte de los sistemas con multiproceso para
proteger el acceso a la memoria y otros recursos compartidos.
Para usar un recurso que está protegido por un lock, la rutina debe primero obtener el
lock para ese recurso. Si el recurso no está disponible (porque lo tiene otra rutina) el
peticionario puede:
Continuar pidiéndolo en un bucle hasta que lo consiga (Spin lock) o quedarse en espera
(suspend lock).
Este esquema posibilita una situación no deseada en la que Usuario A pide lock1 y
usuario B pide lock2. A continuación usuario A pide lock2 y usuario B pide lock1.
Si esto ocurriera, ambos usuarios se quedarían parados en lo que se llama un deadlock
o abrazo mortal.
Para evitar esta situación, los locks z/OS siguen una jerarquía y no se puede pedir uno
de nivel superior sin haber conseguido antes el de nivel inferior.
4.2 Entorno de programación/ejecución
La plataforma System z ofrece las herramientas necesarias para implementar los
estándares de la industria en desarrollo de SW.
El microcódigo de System z ha ido incorporando a lo largo del tiempo, instrucciones
para mejorar el rendimiento de los programas compilados en ejecución.
De la misma manera que se incluyeron instrucciones de microcódigo que mejoraban los
programas Cobol y PL/I, en las últimas versiones se están incluyendo instrucciones que
optimizan programas en Java, C++, Pearl, etc…
IBM Corporation
21/02/2011
51 de 131
4.2.1 Soporte de Runtime- Language environment
En z/OS y z/VM existe un entorno de run-time único para C, C++, COBOL, Fortran,
Assembler y PL/I.
Las librerías de este entorno, incluyen servicios comunes tales como mensajes,
funciones de fecha y tiempo , funciones matemáticas, utilidades, servicios del sistema y
subsistemas
Todos estos servicios, están disponibles a través de interfaces comunes a todos los
lenguajes. Estas interfaces comunes, minimizan la influencia del lenguaje de
programación elegido en los resultados de la aplicación.
4.2.2 ´Compiladores de los lenguajes de programación tradicionales
z/OS soporta los lenguajes de programación clásicos: COBOL, PL/1, Assembler, C/C++
en sus versiones mas recientes.
4.2.3 Soporte de Java
IBM soporta el lenguaje JAVA en todas sus plataformas incluido Systemz. Existe
soporte de Java para todos los sistemas operativos que corren en System z: Linux, por
supuesto, y z/VW así como z/OS.
IBM Corporation
21/02/2011
52 de 131
En z/OS el lenguaje JAVA (es decir la JVM) dispone de los mismos APIs que en el resto
de las plataformas. Pero además IBM ha mejorado el JAVA en z/OS para permitirle
utilizar funciones peculiares de System z, tales como el HW criptográfico o los sistemas
de ficheros UNIX en z/OS.
Además existen interfaces entre los lenguajes tradicionales (Cobol, C/C++, etc..) y el
lenguaje JAVA.
Por último y como se ha dicho anteriormente, la ejecución dentro de la Java Virtual
Machine (JVM) se descarga en su mayoría (alrededor del 90%) en procesadores zAAP
que, como hemos visto, es potencia que no se incluye a la hora de calcular la potencia
de la máquina desde el punto de vista del SW.
Además de poder ser ejecutados de manera interactiva, como en el resto de las
plataformas, los programas Java en z/OS pueden ser ejecutados, también, en batch.
4.2.4 Lenguajes de reciente incorporación
z/OS va incluyendo en sus diferentes versiones el soporte de los distintos lenguajes que
en algún momento se consideran de utilidad en el Mainframe.
Los últimos en ser incluidos (en el z/OS 1.9) han sido Pearl y Metal
También existe el soporte de lenguajes de cuarta generación 4GL para los
programadores mas familiarizados o que prefieren los lenguajes procedimentales frente
a los orientado a objetos como JAVA.
4.2.5 Herramientas de desarrollo de SW
IBM WebSphere Developer for System z V7 incluye capacidades que permiten
desarrollar SW para Mainframe en cualquiera de sus posibilidades.
Esta herramienta permite acelerar el desarrollo de:
•
•
•
•
Piezas de una arquitectura orientada a servicios (SOA) incluyendo servicios
desplegables en CICS, IMS, WebSphere Application Server, y DB2 Stored
Procedure
Aplicaciones Web dinámicas tanto en Java como en J2EE
Aplicaciones tradicionales COBOL, PL/I , C, C++, y High-Level Assembler así
como aplicaciones JAVA para correr bajo JZOS en Z/OS
Servicios Web para integrar esas aplicaciones
Permite también:
Desplegar en múltiples entornos que incluyen WebSphere, CICS, IMS, batch, y DB2 vía
Stored Procedures.
Aprovechar los conocimientos existente para escribir aplicaciones JAVA o Cobol
utilizando EGL(Enterprise Generation Language).
• Adaptar y extender el entorno de desarrollo mediante el uso de diversos plug-in
• Visualizar y editar gráficamente código J2EE usando el UML Visual Editor.
• Detectar problemas de rendimiento y cuellos de botella con las herramientas de
trace y de ‘performance profiling’ para aplicaciones Websphere
• Generar Enterprise COBOL XML para aplicaciones basadas en los servicios
Web de CICS y IMS
IBM Corporation
21/02/2011
53 de 131
•
Generar WSDL y JavaBeans™ para probar y desplegar servicios Web
4.2.6 XML Services
z/OS dispone de diversos modos de ejecutar servicios relacionados con el lenguaje
XML.
El sistema incorpora unas rutinas de parsing de XML a partir de sus últimas releases.
EL gestor de BBDD DB2 que es uno de sus usuarios principales, también dispone de
sus propias rutinas de parsing.
DB2 incorpora un parsing de XML propio, aunque también e
4.2.7 UNIX System Services
Unix System Services, es la componente del sistema operativo que permite ejecutar
programas Unix bajo el control de z/OS.
Es un sistema Unix standard que cumple las especificaciones XPG en sus distintos
niveles.
Además de su disponibilidad para el usuario, hay diversas componentes que lo usan,
como el TCP/IP que ejecuta parte de su código bajo USS y parte bajo una STC. De
esta manera la integración está más optimizada.
4.2.8 Security Server
Como se ha visto anteriormente, la seguridad en System z es una combinación de HW
y SW.
z/OS conjuga la seguridad tradicional hardware, de sistema operativo, subsistemas y
aplicaciones, con nuevos elementos de seguridad de redes y transacciones, que
permite contar con un entorno de seguridad robusto para aplicaciones ebusiness,
reduciendo el número de sistemas y componentes a gestionar.
Los aspectos básicos de seguridad z/OS se sustentan en dos funcionalidades básicas:
• Integridad.- Funciones de aislamiento hardware e integridad del sistema.
• Seguridad de sistema z/OS y sus componentes, que integra la protección de
usuarios y aplicaciones, incluyendo seguridad de red y de transacciones.
Las funciones de aislamiento e integridad han sido descritas con anterioridad, en este
apartado nos centraremos en los aspectos de seguridad.
Los servicios de seguridad z/OS se pueden agrupar en los siguientes bloques:
•
z/OS Cryptographic Services
Las funciones criptográficas incorporan la base de seguridad de red y de transacciones,
permitiendo la utilización de técnicas de cifrado que proporcionan autenticación,
confidencialidad e integridad de datos.
o
ICSF (Integrated Cryptographic Service Facility)
Componente de z/OS para la gestión de los procesadores criptográficos del
zSeries, que proporciona los API de la arquitectura criptográfica de IBM CCA
IBM Corporation
21/02/2011
54 de 131
(Common Cryptography Architecture) a las aplicaciones y middleware que
utilizan los servicios criptográficos software. ICSF es la base fundamental de
criptografía en z/OS posibilitando el cifrado y descifrado de datos, la generación
y gestión de claves y la realización de otras funciones criptográficas de
integridad de datos y firmas digitales.
o
System SSL / TLS (Secure Socket Layer / Transaction Layer Security)
o
Componente base de z/OS que proporciona integración de las funciones SSL
/TLS de autenticación y cifrado (integridad y confidencialidad) a las aplicaciones
y servidores z/OS. Esta integración proporciona servicios de cliente y de
servidor SSL estandarizando y centralizando las funciones de los servicios SSL
y las utilidades de gestión de certificados. System SSL/TLS se beneficia de las
funcionalidades del hardware criptográfico, y de cache del Sysplex para obtener
altas tasas de rendimiento.
PKI Services (Public Key Infrastructure Services)
Componente base de z/OS que proporciona las funciones de gestión de
Autoridad Certificadora estándares (Identrus compliant) en el entorno z/OS.
o
PKI Services soporta X.509 v3 (PKIX) y Common Data Security Architecture
(CDSA), y la gestión de certificados para Secure Sockets Layer (SSL), Internet
Protocol Security (IPSEC) y Secure Multipurpose Internet Mail Extensions
(S/MIME). PKI explota las funcionalidades de protección de RACF y del
hardware criptográfico para la seguridad de comunicaciones y para la protección
de clave privada de CA.
RACF (Resource Access Control facility)
RACF ha sido el componente básico de seguridad del sistema Mainframe
desde sus inicios, centralizando las funciones de seguridad (identificación y
autenticación, control de acceso a recursos y auditoría) para el sistema
operativo y los productos y subsistemas. Las peticiones a RACF se realizan de
manera centralizada y estructurada a través de SAF (System Authorization
Facility (SAF) y su ámbito de cobertura es muy amplio, proporcionando
seguridad tanto a gestores tradicionales con nuevas funcionalidades, como a
nuevos servidores en entorno z/OS, que continuamente está evolucionando
para cubrir las nuevas necesidades. A manera de ejemplo cabe mencionar las
posibilidades de:
o Autenticación de usuarios aplicando diferentes tecnologías: verificación
de usuario con password, password-phrase y passticket; autenticación
de usuarios previamente verificados por otros mecanismos: mapping de
certificados digitales, de Lotus Notes, de Kerberos, traspaso de
identidad entre servidores, etc.
o Control de acceso a recursos granularizado (subsistemas, datos,
transacciones, colas MQ, clases Java, elementos IP, funciones y
privilegios Unix System Services, recursos DB2…) proporcionado por
los gestores de recursos del sistema.
o Gestión de certificados digitales. El RACF puede crear, gestionar y
almacenar certificados digitales, sus claves asociadas RSA/DSA y los
ficheros de claves (key rings), así como generar solicitudes de
certificación a autoridades certificadoras (CA), además de proporcionar
protección de acceso a claves y certificados.
o Log y auditoría integrada en el log del sistema (SMF), incluso para
accesos a recursos no protegidos por RACF (como ficheros y directorios
USS, filas DB2).
IBM Corporation
21/02/2011
55 de 131
4.3 Técnicas de clustering. Sysplex Paralelo
Las técnicas para compartir datos entre más de una imagen del sistema operativo es lo
que generalmente se llaman técnicas de clustering.
Estas pueden ir desde el simple acceso compartido a una unidad de disco con control
manual de la integridad a simple hasta las mas sofisticadas basadas en mecanismos de
‘locking’ y encolamiento.
Entre otros beneficios, estas técnicas previenen la concurrencia no deseada.
La más sofisticada de estas técnicas es la de Sysplex Paralelo
Cada servidor en un Sysplex Paralelo, tiene acceso a todos los recursos (tanto datos
como recursos del sistema) consiguiendo así que en cada uno de los servidores pueda
correr un ‘clon’ de cada aplicación.
La clave es la tecnología que permite compartir los datos con integridad tanto de lectura
como de escritura de manera altamente efectiva.
La tecnología de clustering de sistemas con datos compartidos, ha ido evolucionando
en z/OS desde la compartición básica de datos en discos hasta el Sysplex Paralelo,
pasando por el llamado ‘anillo GRS’.
4.3.1 Clustering básico
Se basa en la protección por un bloque global del dispositivo mientras está siendo
actualizado en algún fichero de uso común. Ej.- VTOCs e índices de los discos,
catálogos, ficheros comunes del online, etc…
No toda actualización implica un bloqueo, ya que aunque se comparten algunos datos,
hay otros muchos que son propios de cada imagen.
Este método bloquea al mismo tiempo toda la información contenida en un dispositivo y
exige, por tanto, una cuidadosa (y bastante estable) configuración del contenido de los
mismos. También exige una cuidadosa `planificación en los accesos para evitar el ‘dead
lock’ arriba descrito.
Pese a sus limitaciones, esta técnica ha permitido a los Mainframe compartir datos
entre distintas instancias del sistema operativo, desde los años 80.
4.3.2 ‘Anillo GRS’
Esta técnica de control de bloqueos es una mejora respecto a la anterior. Da una mayor
granularidad respecto al elemento bloqueado.
Se construye uniendo los sistemas (dos o más) a través de conexiones de canal
formando un anillo.
Cuando desde un sistema se va a actualizar algún elemento compartido (fichero u otro
tipo) lanza una petición que viaja por el anillo para comprobar la disponibilidad del
elemento(y para obtener su control en caso positivo) en cada uno de los sistemas.
Este tipo de técnica se ha utilizado principalmente para:
o Serializar el acceso a ficheros o discos. Esto permite tener una copia
única de los ficheros y evitar duplicados.
o Compartir información acerca de las características de los trabajos. De
esta manera se puede tener una cola de trabajos compartida y sus
elementos se pueden ejecutar en cualquiera de los sistemas
conectados.
o Compartir los controles de seguridad, de forma que las políticas se
apliquen exactamente igual en cada uno de los sistemas.
IBM Corporation
21/02/2011
56 de 131
Esta técnica permite mayor dinamicidad en el contenido de los dispositivos, así como
mayor flexibilidad en la planificación.
La limitación es el delay que introduce en las peticiones y que hace que, en algunos
casos, se siga utilizando la técnica anterior.
Desde su origen, el z/OS ha tenido una componente encargada de la serialización de
acceso a los ficheros llamada GRS( Global Resource Manager). En principio, su utilidad
era proteger el acceso a los ficheros y recursos desde las distintas aplicaciones que se
ejecutan en los distintos AS.
La primera componente del sistema que utilizó el anillo de canales para extender la
serialización de intra-sistema a inter-sistema fue el GRS y de ahí la denominación de
‘anillo GRS’.
Esta técnica se ha estado utilizando hasta hace pocos años.
4.3.3 Sysplex Paralelo (Resource sharing y Datasharing)
Un Sysplex Paralelo, es una colección de sistemas z/OS que cooperan para procesar
los trabajos como si fueran un único sistema. Para esto se utilizan tanto piezas de HW
como de SW.
Esta tecnología es la base de la obtención de la disponibilidad continua. Al haber mas
de una instancia de z/OS procesando trabajos, una parada (por error o planificada) de
uno de ellos no implica una parada en el servicio, ya que el resto de imágenes de la
aplicación siguen funcionando.
Sysplex paralelo, también posibilita un crecimiento ‘horizontal’ (añadir un sistema con
su potencia al conjunto) frente al crecimiento ‘vertical’ (añadir potencia simplemente).
Este crecimiento horizontal amplia el techo de crecimiento con System z. El límite
teórico en la actualidad es de 32 sistemas con 64 procesadores cada uno.
El Sysplex Paralelo esta basado en una tecnología que permite el acceso compartido a
bajo coste en overhead y con la integridad asegurada.
De esta forma las transacciones o unidades de trabajo se pueden ejecutar
indistintamente en cualquiera de los sistemas que componen un Sysplex.
Las componentes de una configuración de Sysplex paralelo son:
Recursos HW- Coupling Facilities y Coupling Links
Recursos SW:
SW que se ejecuta en la CF
Adaptación del SW para usar las Interfases de accesos a la CF
4.3.4 Coupling Facility
Una Coupling Facility es el conjunto formado por uno o más procesadores, unos GB de
memoria , conexiones con los sistemas del Sysplex y un sistema operativo propio que
se distribuye a la vez.
IBM Corporation
21/02/2011
57 de 131
La CF funciona como una gran buffer donde los datos pueden ser accedidos desde los
sistemas con un mecanismo de serialización adecuado al tipo de dato.
Los Información que almacena es de tres tipos
•
Información de lock que es compartida entre todos los sistemas del Sysplex
•
Información de cache (por ejemplo los datos de seguridad o los datos de la
BBDD de empleados)
•
Lista de datos
La Coupling Facility puede ser un sistema aparte o una LPAR dentro de un sistema.
En la figura se ve la configuración de un Sysplex paralelo con 2 imágenes.
Como funcionalidades más relevantes de un Sysplex Paralelo, se podrían destacar las
siguientes:
•
En muchos aspectos, un Sysplex Paralelo parece un único sistema.
•
Tiene una internase única de operación
•
Planificando adecuadamente, una carga se puede ejecutar en una o varios
sistemas
IBM Corporation
21/02/2011
58 de 131
•
Si uno de los sistemas falla, y los sistemas están preparados para ello (ver
GDPS mas adelante) su carga es desviada automáticamente al resto sin
pérdida de servicio.
•
De la misma forma, si algún de los sistemas necesita mantenimiento, su carga
se puede desviar al resto sin pérdida de servicio. Esto hace que incluso
actualizaciones HW (cambio de máquinas) o de SW (cambio de Sistemas
Operativos) se puedan llevar a cabo sin pérdida de servicio. Por supuesto con
los límites de compatibilidad entre versiones que marca la política de IBM.
4.4 z/VM
z/VM es un Sistema operativo basado en la z/Architecture (64-bit) y que corre en la
plataforma System z.
VM son las siglas de Virtual Machine y este sistema operativo es, como indica su
nombre, la implementación de la tecnología IBM para virtualización de servidores en la
plataforma. Cada máquina virtual es vista por el sistema operativo ‘guest’ o huésped
como una máquina física.
Da la capacidad de correr otro tipo de sistemas operativos cono z/VSE o zLinux y
también z/OS puede ser ejecutado bajo z/VM.
z/VM soporta huéspedes en arquitecturas de 24, 31 y 64 bits.
z/VM suministra a cada usuario un entorno de trabajo individual, que es lo que
llamamos máquina virtual, que el usuario ve como HW y se dirige a él utilizando las
instrucciones HW que usaría en modo nativo.
Las máquinas virtuales bajo z/VM comparten todos los recursos del sistema
El procesador y la memoria son asignados a los servidores que la necesitan cuando la
necesitan. La asignación del procesador es por intervalos, es decir que se tiene una
granularidad menor que un procesador.
z/VM también permite virtualizar la E/S ( discos, cartuchos, etc. ) así como la red.
La virtualización permite además enriquecer el entorno por medio de funciones tales
como:
•
Uso de técnicas de ‘Data in Memory’ para mejorar el rendimiento de la E/S. Un disco
virtual puede estar en memoria.
•
Simular Procesador, memoria y dispositivos que no existen en el HW real.
•
Compartir una copia única del kernel entre distintos huéspedes.
z/VM permite compartir espacio en disco entre las imágenes zLinux. Esto permite que
se pueda compartir el código read-only entre dichas imágenes.
Esta facilidad, además de mejorar el uso del espacio en disco, permite gestionar mejor
las versiones de las aplicaciones y reduce la complejidad del mantenimiento del SW.
La comunicación entre los distintos sistemas huéspedes es también virtual. Además de
ser más rápida, ya que los datos no salen de la memoria del procesador, simplifica
enormemente el cableado y mejora la seguridad reduciendo la necesidad de Firewalls
intermedios,
IBM Corporation
21/02/2011
59 de 131
4.5 Linux en System z
IBM apostó desde el principio por Linux como sistema operativo multiplataforma y
colabora con la comunidad Linux para proveer interfaces con el HW Systemz.
Linux en System z, soporta, por tanto los procesadores como los dispositivos propios de
la plataforma.
Hay dos distribuciones ‘oficiales’ que suministran Linux capaces de ejecutarse en
System z:
_ Novell SUSE
_ Red Hat
Linux on System z es el mismo Linux que en el resto de las plataformas. Tiene la
misma funcionalidad que el S.O. Linux en otras plataformas, con el añadido del soporte
y uso del HW del que dispone System z.
•
Soporte Criptográfico : PCICA, CPA, PCIXCC, CryptoExpress2, CryptoExpress3
•
I/O Mainframe y distribuido- Protocolo Ficon y/o SCSI
•
Soporte de OSA-Express ,OSA-Express2 y OSA-Express3 para comunicación
de alta velocidad fuera del CEC.
•
HiperSockets para comunicación de muy alta velocidad dentro del CEC, entre
particiones con z/OS, z/VSE y Linux. HiperSockets es una funcionalidad de
System z que permite una comunicación TCP/IP a alta velocidad entre LPAR.
Usa la memoria como canal de comunicación y usa un protocolo TCP/IP
aligerado de las funciones relativas al medio físico.
En general, zLinux hereda de manera automática, las fortalezas del HW del Mainframe.
Usado como huésped de z/VM suministra una base para la consolidación de servidores
muy eficiente, muy escalable, capaz de soportar altos niveles de carga cercanos al
100% y por lo tanto muy efectivo desde el punto de vista del coste.
IBM Corporation
21/02/2011
60 de 131
5 Arquitectura System z. Plataforma
Middleware Transaccional
SW-
Las transacciones ocurren en nuestra vida diaria constantemente; por ejemplo cuando
sacamos dinero de un cajero o buscamos en Internet. Una transacción es un
intercambio, generalmente una petición y su respuesta, que ocurre como un hecho
rutinario para ejecutar operaciones del día a día de una organización. Las transacciones
tienen las siguientes características:
•
Se procesan y transfieren pequeños volúmenes de información por cada
transacción.
•
Tienen gran número de usuarios.
•
La duración es corta.
•
Se ejecutan con mucha frecuencia o en grandes cantidades.
•
Los datos que manejan son compartidos.
Una transacción de negocio es un acuerdo de negocio autocontenido. Algunas
transacciones suponen una conversación corta (por ejemplo, el cambio de un domicilio).
Otras, por el contrario, acarrean varias acciones que tienen lugar a lo largo de un
periodo de tiempo más o menos amplio (por ejemplo, la reserva de un viaje, incluyendo
coche, hotel y billetes de avión).
Una transacción simple puede constar de muchos programas de aplicación que llevar a
cabo el proceso requerido. Los sistemas transaccionales de alta capacidad como CICS
se ayudan de las capacidades de multitarea y multithread del z/OS para procesar más
de una tarea en un momento determinado, cada una guardando sus propios datos
variables y siguiendo las instrucciones específicas del usuario que la ejecuta.
La capacidad de multitarea es fundamental en cualquier entorno en el que se conecten
miles de usuarios al mismo tiempo. Cuando un sistema transaccional multitarea recibe
una petición para ejecutar una transacción, puede arrancar una nueva tarea que se
asocia con una instancia de la ejecución de la transacción, o lo que es lo mismo con su
conjunto particular de datos para un determinado usuario en un terminal determinado.
La capacidad de multithreading permite que una copia simple de un programa de
aplicación se procese por varias transacciones concurrentemente. Se requiere que
todos los programas de aplicación transaccional sean reentrantes, o lo que es lo mismo,
los programas deben ser reusables en serie entre puntos de entrada y salida; la
reentrancia se asegura obteniendo una copia nueva de la memoria de trabajo cada vez
que se invoca el programa.
En un sistema transaccional, las transacciones deben cumplir con cuatro
requerimientos primarios, conocidos en conjunto con el nemotécnico A-C-I-D o ACID:
IBM Corporation
21/02/2011
61 de 131
Atomicidad – los procesos ejecutados por la transacción o se ejecutan como un todo o
no lo hacen en absoluto.
Consistencia – la transacción sólo trabaja con información consistente.
Isolation (aislamiento) – los procesos que proceden de dos o más transacciones deben
estar aislados entre sí.
Durabilidad – los cambios hechos por la transacción deben ser permanentes.
Generalmente las transacciones se inician por usuarios finales que interactúan con el
sistema transaccional a través de un terminal. En el pasado, los sistemas
transaccionales sólo soportaban terminales y dispositivos conectados a través de una
red de teleproceso 2. Hoy día los sistemas transaccionales pueden servir peticiones
provenientes de:
•
•
•
•
Una página web
Un programa en una estación de trabajo remota
Una aplicación en otro sistema transaccional
Un disparo automático en un momento predefinido o ante un suceso
determinado
En los siguientes puntos se detallan cada uno de los servidores de aplicación
transaccionales.
5.1 CICS
CICS son las iniciales de Customer Information Control System 3; es un subsistema de
propósito general del z/OS para procesar transacciones.
El CICS proporciona los servicios para ejecutar una aplicación online, a petición, y al
mismo tiempo que otros usuarios están submitiendo peticiones para ejecutar la misma
aplicación utilizando los mismos ficheros y programas.
El CICS gestiona la compartición de los recursos, la integridad de los datos y la
priorización de la ejecución de las aplicaciones. El CICS autoriza a los usuarios, aloca
los recursos (memoria y procesamiento), y pasa las peticiones de bases de datos de las
aplicaciones al gestor de base de datos correspondiente (por ejemplo, DB2). Podríamos
decir que el CICS actúa (y lleva a cabo muchas de las mismas funciones) como el
sistema operativo z/OS.
Una aplicación CICS es una colección de programas relacionados que llevan a cabo
juntos una operación de de negocio, como presentar una declaración de renta por vía
telemática o abrir una solicitud de ayuda para personas con dependencia.
2
De aquí deriva la denominación de monitores de teleproceso que se ha dado tradicionalmente a
los sistemas transaccionales.
3
Aunque desde hace unos años al nombre CICS se le han añadido las iniciales TS de
Transaction Server, en este libro seguiremos refiriéndonos a este middleware como CICS a
secas.
IBM Corporation
21/02/2011
62 de 131
Las aplicaciones se ejecutan bajo control del CICS utilizando servicios CICS e
interfaces para acceder a programas y ficheros. La ejecución de una transacción
incluye la ejecución de uno o más programas de aplicación que implementan la función
que se requiere. En la documentación de CICS se puede encontrar que a los
programas de aplicación CICS se les llama simplemente programas, y algunas veces el
término transacción se usa para indicar el proceso hecho por los programas de
aplicación.
5.1.1 El CICS y el z/OS
En un sistema z/OS, el CICS proporciona el nivel funcional para gestionar las
transacciones, mientras el sistema operativo sigue siendo la interfaz final con el
hardware. El CICS separa fundamentalmente un tipo particular de programa de
aplicación (la llamada aplicación online) de otros en el sistema, y los gestiona él mismo.
Cuando un programa de aplicación accede a un terminal o a cualquier dispositivo, por
ejemplo, no se comunica con él directamente. El programa lanza comandos para
comunicarse con el CICS, qué a su vez se comunica con los métodos de acceso
correspondientes del sistema operativo. Finalmente, el método de acceso se comunica
con el terminal o dispositivo.
Figura n: Sistema transaccional y sistema operativo
Un sistema z/OS podría tener múltiples copias de CICS ejecutándose a la vez. Cada
CICS arranca un espacio de direcciones z/OS separado. El CICS proporciona una
opción llamada operación multiregión (MRO son las iniciales en inglés), y que permite la
separación de funciones CICS diferentes en regiones diferentes (espacios de
direcciones); así un espacio de direcciones CICS (o más) podría hacer el control de los
terminales y se le llamaría terminal-owning regions (TOR). Otras posibilidades incluyen
application-owning regions (AORs) para las aplicaciones y file-owning regions (FORs)
para los ficheros.
IBM Corporation
21/02/2011
63 de 131
5.1.2 Programas, transacciones y tareas CICS
El CICS permite separar la lógica de la aplicación de los recursos de la aplicación. Para
desarrollar y ejecutar transacciones CICS, se necesita entender la relación entre los
programas CICS, transacciones y tareas. Estos términos se usan a lo largo de las
publicaciones CICS y aparecen en muchos comandos.
•
Transacción.- Es una pieza de procesamiento iniciada por una simple petición. Se
puede iniciar desde un usuario en un terminal, pero también desde una página web,
o desde un programa en una estación de trabajo remota, una aplicación en otro
sistema transaccional o por un disparo automático en un momento predefinido o
ante un suceso determinado. A cada transacción se le da un nombre de cuatro
caracteres, que se define en la tabla de control de programas (PCT).
•
Programa de aplicación.- Una transacción simple puede constar de uno o más
programas de aplicación, y que cuando se ejecutan, llevan a cabo el procesamiento
requerido. Sin embargo, el término transacción en CICS significa tanto un sencillo
evento o todas las transacciones del mismo tipo. Cada transacción se describe en
el CICS con la definición de recurso transacción (transaction resource definition).
Esta definición le da a la transacción un nombre (identificador de la transacción o
TRANSID) e informa a CICS de varias cosas como qué programa se invoca desde
el principio y qué tipo de autenticación se requiere durante la ejecución de la
transacción. Se ejecuta la transacción especificándole al CICS el nombre de la
transacción (TRANSID); éste usa la información guardada en la definición de la
transacción para establecer el entorno de ejecución adecuado, y arrancar el primer
programa.
•
Unidad de trabajo Utilizamos este término para denominar a una operación
completa que es recuperable; puede ser confirmada o deshecha en su totalidad
como resultado de un comando programado o fallo del sistema. En muchas
ocasiones, el ámbito de una transacción CICS es el de una sola unidad de trabajo.
•
Tarea La palabra tarea también tiene un significado especial en CICS. Cuando el
CICS recibe una petición para ejecutar una transacción, arranca una nueva tarea
asociada con esta instancia de la ejecución de la misma. A la tarea se le puede
también considerar como un thread, Cuando la transacción se completa, se termina
la tarea.
5.1.3 Programación conversacional y pseudo-conversacional
En CICS, cuando los programas que se están ejecutando entran en conversación con el
usuario hablamos de transacción conversacional. Una transacción no conversacional,
por el contrario, procesa una entrada, responde y acaba (desaparece). Nunca se queda
parada (en pausa) para leer una segunda entrada que le venga del terminal, de manera
que no hay una conversación real. Hay una técnica en CICS que se llama
procesamiento pseudo-conversacional en el que a través de una serie de transacciones
no conversacionales se da la apariencia al usuario de que existe una transacción
conversacional. No existe transacción mientras el usuario está esperando por la
entrada; cuando éste la envía, el CICS arranca la transacción para leer y procesar los
datos; justo después de enviar respuesta de nuevo al usuario, acaba la transacción. Es
fundamental entender que la principal diferencia entre ambas técnicas radica en los
recursos que están alocados en cada momento; mientras en la transacción
conversacional los programas mantienen los recursos mientras esperan a recibir los
IBM Corporation
21/02/2011
64 de 131
datos, en el caso de la programación pseudo-conversacional, no se mantiene alocado
ningún recurso durante estas esperas.
5.1.4 Comandos CICS
El formato general de un comando CICS es EXECUTE CICS (o EXEC CICS) seguido
por el nombre del comando y posiblemente una o más opciones. Cuando se necesita
un servicio del CICS, por ejemplo para leer un registro de un fichero, sólo tienen que
incluirse el comando CICS dentro del código del programa.
5.2 Servicios CICS para los programas de aplicación
El API CICS proporciona acceso a un junto amplio de servicios que pueden usarse para
construir aplicaciones.
Los programas CICS que usan el API pueden llevar a cabo las siguientes operaciones:
•
Acceso a datos en ficheros VSAM y BDAM y en bases de datos DB2 e IMS.
•
Comunicación con variedad de terminales y dispositivos.
•
Conexión a programas en otras plataformas que usan protocolos SNA y TCP/IP.
•
Interactuar con clientes y servidores HTTP.
•
Operar como un peticionario o proveedor de servicios web.
•
Intercambiar datos con otros programas en la misma transacción y con otras
transacciones.
Los programas CICS se ejecutan como parte de una transacción bajo el control de una
tarea CICS y pueden llevar a cabo las siguientes acciones:
•
Obtener información sobre el entorno del programa.
•
Iniciar otras transacciones inmediatamente o en el futuro.
•
Confirmar o deshacer la unidad de trabajo en curso.
•
Reservar o liberar bloqueos sobre los recursos que se comparten con otras
tareas.
•
Ajustar la prioridad de la tarea, y dejar el control a favor de otras tareas que
tienen mayor prioridad.
•
Identificar y autenticar usuarios que inician transacciones mediante los servicios
de un gestor de seguridad externo.
•
Capturar datos en journals que se pueden usar para reconstruir eventos o
cambios a los datos.
•
Interactuar con el sistema operativo, incluyendo la consola del sistema y el
spool del JES.
IBM Corporation
21/02/2011
65 de 131
5.2.1 Objetos de datos CICS
El CICS proporciona determinados objetos que los programas y las transacciones
pueden emplear para intercambiar datos con otras.
Áreas de comunicación Un área de comunicación (COMMAREA) es un simple bloque
de memoria que se usa para pasar datos entre programas. Un programa solo puede
pasar una COMMAREA a otro programa. El tamaño máximo recomendado de un área
de comunicación es de 24KB, aunque el valor máximo absoluto es de 32KB.
Contenedores y canales (containers and channels) Un contenedor es un bloque de
datos con nombre que se usa para pasar información entre programas. El programa
puede pasar cualquier número de contenedores a otro programa usando una
agrupación lógica de contenedores llamada canal. Los contenedores no están limitados
a un tamaño máximo de 32KB.
Colas temporary storage (TS) Una cola TS es una cola de items de datos con nombre
que se pueden escribir, reescribir, leer, y releer, en cualquier secuencia. Se pueden
definir colas TS como recuperables.
Colas transient data (TD) Una cola TD es una cola de items de datos con nombre que
se puede escribir y leer sólo una vez. Se deben leer secuencialmente, y cada item de
datos sólo se puede leer una vez; después de que una transacción lee un item, éste se
borra de la cola y deja de estar disponible para cualquier otra transacción.
El CICS proporciona dos tipos de colas TD:
•
Colas TD intrapartición que se usan principalmente para comunicación entre los
programas CICS.
•
Colas TD extrapartición que se usan principalmente para comunicación entre un
programa CICS y un dispositivo secuencial, como un fichero QSAM o una
impresora.
Las colas TD intrapartición se pueden definir como recuperables.
5.2.2 Acceso a datos externos
El CICS soporta acceso a datos externos en bases de datos DB2 e IMS/DB, así como a
ficheros VSAM y BDAM.
En el caso del DB2, los programas CICS emplean sentencias SQL y el acceso se hace
a través de la llamada CICS DB2 attachment facility.
Los programas pueden usar tanto la interfaz de comando DL/I o la de llamada para
acceder a datos en bases de datos DL/I. El acceso se lleva a cabo a través de
Database Control (DBCTL).
Los programas CICS pueden utilizar la interfaz de programación de aplicaciones para
leer o escribir datos en ficheros manejados por VSAM (Virtual Storage Access Method)
y BDAM (Basic Direct Access Method). Como se pudo ver en el ejemplo contenido en la
sección anterior, el CICS no se refiere directamente al nombre del fichero (data set),
sino que lo hace a un file, que es un recurso CICS mapeado al verdadero fichero
mediante una definición. Se pueden usar tablas de datos compartidos (shared data
tables) para proporcionar un acceso eficiente a los ficheros VSAM KSDS. Una tabla de
IBM Corporation
21/02/2011
66 de 131
datos es un fichero que tienen los registros en memoria principal; una tabla de datos
compartidos es una tabla de datos que está accesible desde más de una región CICS.
5.2.3 Topología CICS
Se pueden distribuir las aplicaciones CICS y sus recursos entre regiones CICS
interconectadas. Las regiones CICS se pueden agrupar en grupos de sistemas CICS y
en CICSplexes, y las regiones se pueden distribuir entre sistemas z/OS que formen
parte de un Sysplex.
Un Sysplex es un conjunto de sistemas z/OS que se comunican y cooperan entre sí a
través de componentes hardware y servicios de software multisistema.
Una región CICS es una instancia (ejemplar) de CICS que se ejecuta en su propio
espacio de direcciones z/OS. Una región CICS se puede arrancar y parar
independientemente de otras regiones.
Un CICSplex es una agrupación de regiones CICS que se maneja como una sola
entidad. Cada región CICS sólo puede pertenecer a un CICSplex. Un CICSplex puede
incluir regiones CICS de diferentes sistemas z/OS de un Sysplex.
Un grupo de sistemas CICS es una agrupación de regiones en un CICSplex que se
puede manejar como una entidad. El grupo puede incluir regiones que se estén
ejecutando en sistemas z/OS diferentes. En un CICSplex, cada región puede
pertenecer a más de un grupo, y los grupos pueden estar contenidos en otros grupos.
En la sección El CICS y el z/OS se citaba el concepto de operación multiregión; las
diferentes funciones especificadas corresponden a los diferentes roles que las regiones
CICS pueden llevar a cabo en un CICSplex. Todas las regiones CICS pueden
desempeñar todos los roles y, en algunos casos, resulta apropiado combinar algunos
de los roles en una región.
Un sistema z/OS podría tener múltiples copias de CICS ejecutándose a la vez. Cada
CICS arranca un espacio de direcciones z/OS separado. El CICS proporciona una
opción llamada operación multiregión (MRO son las iniciales en inglés), y que permite la
separación de funciones CICS diferentes en regiones diferentes (espacios de
direcciones); así un espacio de direcciones CICS (o más) podría hacer el control de los
terminales y se le llamaría terminal-owning regions (TOR). Otras posibilidades incluyen
application-owning regions (AORs) para las aplicaciones y file-owning regions (FORs)
para los ficheros.
Hay un tipo particular de región que es la llamada transport-owning region, y que realiza
la conexión de un CICSplex a la red.
Todos los conceptos de topología CICS pueden verse recogidos en la siguiente figura:
IBM Corporation
21/02/2011
67 de 131
Figura n+1: Cómo se organizan las regiones CICS en un Sysplex
5.2.4 Intercomunicación CICS a CICS
El CICS proporciona diferentes formas para conectar regiones CICS entre sí dentro del
mismo sistema z/OS, entre regiones en el mismo Sysplex z/OS, y entre regiones en
Sysplexes distintos.
La operación multiregión (MRO) ya citada con anterioridad se emplea para comunicar e
intercambiar datos sin necesitar de una red de comunicación externa.
La Intersystem Communication (ISC) se usa para comunicar regiones CICS entre sí y
con otros sistemas usando protocolos SNA.
Se puede utilizar interconectividad IP (IPIC) para comunicar regiones CICS entre sí y
con otros sistemas usando TCP/IP.
Se pueden utilizar facilidades de intercomunicación CICS para distribuir el trabajo de
una aplicación entre un número de regiones CICS, permitiendo así que programas en
una región usen recursos en otra. Estas facilidades son function shipping, asynchronous processing, transaction routing, distributed program link y distributed transaction
processing.
Resulta destacable que la gestión de cargas permite la distribución de las peticiones
entre las regiones CICS que puedan procesarlas de la forma más eficiente. Los dos
aspectos de la gestión de cargas son la separación de éstas y el balanceo. El primero
permite la distribución del trabajo entre regiones objetivo de acuerdo a atributos de la
petición, mientras que el segundo distribuye el trabajo de acuerdo a los niveles de
disponibilidad y actividad de las regiones objetivo.
5.2.5 Conectividad con sistemas no-CICS
Las aplicaciones CICS se pueden comunicar con sistemas no-CICS o en modo peer-topeer o en modo cliente servidor, mediante protocolos de comunicación estándar de la
industria. En la configuración cliente servidor, cada nodo tiene un role distinto: el cliente
envía peticiones a un servidor y el servidor devuelve la información solicitada al cliente.
En el modo peer-to-peer, ambos nodos tienen roles iguales, asumiendo los del cliente y
del servidor.
Los protocolos usados son TCP/IP, Servicios Web, HTTP, SNA y Remote Procedure
Call (RPC).
IBM Corporation
21/02/2011
68 de 131
El CICS proporciona interfaces para que se puedan enviar peticiones a una región
CICS desde un sistema externo:
•
CICS Transaction Gateway – es un producto que permite invocar programas en
CICS desde una aplicación Java mediante interfaces J2EE.
•
Clientes CICS – estos son miembros de la familia de productos CICS de la
estación de trabajo que proporcionan un conjunto estándar de funciones para
iniciar transacciones CICS mediante external call interface (ECI) o external
presentation interface (EPI). ECI es un API para que un programa en un cliente
llame a un programa CICS y se intercambien datos a través de COMMAREA.
EPI es un API que permite que un programa en un cliente simule un terminal
3270.
•
Bridge CICS-MQ – para que se puedan iniciar transacciones CICS desde
aplicaciones de WebSphere MQ.
•
Interfaz de sockets de TCP/IP para CICS – es parte del software
Communications Server de z/OS y soporta comunicaciones peer-to-peer entre
programas CICS y otras aplicaciones que usan protocolos TCP/IP.
•
External CICS Interface (EXCI) – la interfaz permite que un programa en z/OS
pueda invocar un programa CICS utilizando distributed program link (DPL).
5.2.6 Configuración CICS
La región CICS se pude configurar y controlar su comportamiento a través de los
parámetros de inicialización de sistema, creando e instalando definiciones de recursos,
y escribiendo exits de usuario (user exits).
En la actualidad se puede emplear una herramienta de gestión del sistema llamada
CICS Explorer que permite manejar de una forma simple y centralizada uno o más
sistemas CICS. Está basada en Eclipse 4 y permite llevar a cabo funciones como las
siguientes: visualizar definiciones de recursos, crearlas y actualizarlas e instalarlas o
eliminarlas; en cuanto a recursos CICS, habilitarlos y deshabilitarlos, abrirlos y
cerrarlos, adquirirlos y liberarlos, ponerlos en servicio y fuera de servicio o acabar
tareas asociadas con un recurso.
5.2.7 Seguridad
El CICS usa los servicios que le proporciona un gestor de seguridad externo, como el
RACF, para el control de los accesos a las aplicaciones y a los recursos del sistema.
Sea cual sea la forma de iniciarse una transacción, cuando la seguridad del CICS está
activa, la transacción queda asociada con un usuario. Aunque un usuario CICS es en
muchos casos un usuario individual concreto, en general un usuario es una entidad que
se identifica con un identificador de usuario (user ID).
Cuando un usuario hace una petición, el CICS llama al gestor de seguridad para
determinar si tiene la autoridad para hacerla. Si el usuario no tiene la autoridad
apropiada, el CICS deniega la petición.
4
Eclipse es una plataforma para construir y desplegar aplicaciones cliente en las que
la manipulación de datos es Rich Client Platform (RCP).
IBM Corporation
21/02/2011
69 de 131
El CICS chequea la autoridad del usuario a diferentes niveles:
•
Seguridad de signon que asegura que los usuarios del terminal están
autorizados a conectarse a CICS
•
Seguridad del enlace que asegura que los sistemas remotos están autorizados
a conectase a CICS
•
Seguridad de transacción que los usuarios que intentan ejecutar una
transacción están autorizados a ello.
•
Seguridad de recurso que asegura que los usuarios que usan recursos CICS
están autorizados a ello.
•
Seguridad de comando para asegurar que los usuarios que usan la interfaz de
programación CICS están autorizados a ello.
Para llevar a cabo la identificación y la autenticación de los usuarios, el CICS puede
usar los identificadores de usuario y passwords o los certificados de cliente SSL.
5.2.8 Herramientas para depuración y de determinación de problemas
El CICS proporciona un conjunto de herramientas para la depuración de los programas
de aplicación y para el diagnóstico de problemas en el sistema. Estas incluyen soporte
para las herramientas de depuración basadas en la estación de trabajo, execution
diagnostic facility (EDF), mensajes, trace y dump.
En el caso de las herramientas de depuración basadas en la estación de trabajo, estas
constan de dos componentes principales:
•
Un cliente que se ejecuta en la estación de trabajo que permite interactuar con
el programa de aplicación a través de interfaz gráfica. Se pueden crear puntos
de ruptura para ir parando el programa y examinando las variables usadas en el
mismo.
•
El servidor que se ejecuta en la misma región CICS del programa de aplicación
y que se comunica con la parte cliente.
La utilidad EDF se usa para probar los programas de aplicación interactivamente, sin
hacer modificaciones al programa fuente o al procedimiento de preparación del
programa. El EDF intercepta la ejecución del programa en varios puntos y muestran la
información de éste.
El CICS emite mensajes para advertir de eventos significativos y de condiciones de
error y, en algunos casos, solicitar información del operador del sistema. Los mensajes
se emiten a la consola del sistema, a terminales CICS o a destinos de colas TD.
El trace es un registro del procesamiento hecho por un programa o transacción. La
información recolectada de un trace se puede usar para determinar problemas,
especialmente de rendimiento. El CICS tracea el flujo de control a través de su código.
Los eventos clave que recolecta en el trace son la entrada y la salida a programas del
sistema CICS y eventos excepcionales. También se pueden tracear programas de
aplicación del usuario. Se puede capturar la información del trace internamente, en
ficheros auxiliares de trace, y en el fichero GTF del z/OS. Se puede seleccionar qué
información de trace se captura, aunque el trace de las excepciones siempre se recoge.
Un dump es un registro de los contenidos de áreas seleccionadas de memoria principal
en un instante determinado. El CICS captura un dump cuando se produce un fallo o
IBM Corporation
21/02/2011
70 de 131
cuando se pide sacarlo explícitamente. El CICS proporciona dos tipos de dump, uno de
transacción que captura áreas de memoria relativas a una cierta transacción, y uno de
sistema que captura todas las áreas de memoria de una región CICS.
5.3 IMS
El IMS, Information Management System, ha sido una parte importante de la industria
de las tecnologías de la información desde su inicio.
El 25 de Mayo de 1961, el Presidente de los EEUU John F. Kennedy retó a la industria
americana a mandar un americano a la Luna y que volviera sano y salvo a la Tierra. La
hazaña se vio cumplida antes del final de la década como parte del programa Apolo.
American Rockwell ganó el contrato para construir una nave para el programa Apolo y,
en 1965, crearon un acuerdo con IBM para disponer de un sistema automatizado que
gestionara las grandes cantidades de piezas necesarias para la construcción de
aquélla.
En 1966, 12 miembros de un equipo de IBM, junto con 10 miembros de American
Rockwell y 3 de Carterpillar, empezaron a diseñar y desarrollar el sistema que se llamó
Information Control System and Data Language/Interface (ICS/DL/I). Durante el proceso
de diseño y desarrollo, el equipo de IBM se desplazó a Los Angeles y creció hasta los
21 miembros. El equipo de IBM completó y proporcionó la primera release del ICS en
1967.
En Abril de 1968, se instaló. El 14 de Agosto de 1968, se vio el primer mensaje de
“READY” en un terminal de máquina de escribir IBM 2740 en la división espacial de
Rockwell en la NASA en Downey, California.
En 1969, se renombró el ICS como Information Management System/360 (IMS/360) y
pasó a estar disponible en todo el mundo de IT.
Desde 1968, el IMS:
•
Ayudó a la NASA a cumplir con el sueño del Presidente Kennedy.
•
Empezó la revolución de los sistemas gestores de bases de datos.
•
Continúa evolucionando para cubrir (y sobrepasar) los requerimientos
demandados por los negocios y gobiernos en la actualidad.
El sistema gestor de bases de datos IMS (DBMS) introdujo la idea de que el código de
la aplicación se separara de los datos. El punto de separación era el DL/I, Data
Language/Interface. El IMS controla el acceso y la recuperación de los datos. Los
programas acceden y navegan por los datos invocando a la interfaz estándar DL/I.
Esta separación estableció un nuevo paradigma en la programación de aplicaciones. El
código de aplicación ahora se podía focalizar en la manipulación de los datos sin las
complicaciones y la sobrecarga asociada al acceso y a la recuperación de los datos.
Este paradigma eliminaba virtualmente la necesidad de copias redundantes de los
datos. Diferentes aplicaciones podían acceder y modificar una instancia de los datos,
proporcionando así el dato vigente a cada aplicación. Se hizo más fácil el acceso a los
datos de forma online ya que el código de la aplicación se separaba del control de los
propios datos.
IBM desarrolló un componente online para el ICS/DL/I con el fin de soportar la
comunicación de los datos. Se amplió la interfaz DL/I al componente online del
producto para permitir la transparencia de comunicación de los datos a los programas
IBM Corporation
21/02/2011
71 de 131
de aplicación. Se creó una función de cola de mensajes para mantener la integridad de
los mensajes de comunicación de datos y para proporcionar planificación a los
programas de aplicación. El componente online del ICS/DL/I se convirtió finalmente en
la función Data Communications (DC) del IMS, y que a su vez pasó a ser IMS
Transaction Manager en el IMS Versión 4.
IMS se unió al Mainframe oficialmente en 1969. Se ha reinventado varias veces desde
entonces. La aceptación de los clientes de las nuevas versiones de IMS es la mejor
medida de su valor estratégico. En el 2003 la carga IMS medida como capacidad de los
sistemas en MIPS se había incrementado en un 67.9% en las últimas versiones. Sobre
el 90% de las principales compañías en el mundo usan IMS para ejecutar sus
operaciones diarias. IMS todavía es una plataforma viable, en algunas ocasiones sin
rival, para desplegar sistemas de alto procesamiento transaccional y, en combinación
con tecnología de servidores web de aplicación, es la base para una nueva generación
de aplicaciones.
Veamos unos cuantos hechos sobre cómo se usa el IMS:
•
Alrededor del 95% de las compañías del Fortune 1000 usan IMS.
•
IMS gestiona alrededor de 15 millones de gigabytes de datos de producción.
•
IMS procesa alrededor de 50 billones de transacciones por día.
•
IMS sirve a 200 millones de usuarios todos los días.
•
IMS procesa alrededor de 100 millones de transacciones por día para un
cliente.
•
Y 120 millones de transacciones para otro (7 millones por hora).
•
IMS puede procesar 21.000 transacciones por segundo (alrededor de 1 billón al
día) utilizando IMS data sharing y colas compartidas.
•
Un solo IMS ha procesado unas 6.000 transacciones por segunda con una sola
conexión TCP/IP.
En resumen,
•
El gestor de bases de datos (IMS DB)
•
El gestor transaccional (IMS TM)
•
Un conjunto de servicios de sistema que proporcionan servicios comunes al IMS
DB y al IMS TM.
En la siguiente figura pueden verse los tres componentes relacionados.
IBM Corporation
21/02/2011
72 de 131
Diagrama general del IMS
Conocido en conjunto como IMS DB/DC, los tres componentes crean un entorno de
proceso de transacciones completo que aporta disponibilidad continua e integridad de
datos. Las funciones que proporcionan estos componentes se describen con detalle
más adelante.
El IMS se ha desarrollado para proporcionar un entorno para las aplicaciones que
demandan altos niveles de rendimiento, capacidad y disponibilidad. El IMS usa mucha
de las facilidades que ofrece el sistema operativo y el hardware. Se ejecuta en z/OS y
System z.
El IMS TM e IMS DB pueden ser componentes independentes si no se requieren nada
más que las funciones de uno de ellos. Cuando se utiliza sólo el IMS DB, se le llama
DBCTL, y si el que se utiliza es el IMS TM, se le llama DCCTL.
Los programas de aplicación que se escriben para usar las funciones de IMS se pueden
codificar en Assembler, C/C++, COBOL, Java, Pascal, PL/I y REXX. Las aplicaciones
acceden a los recursos IMS llamando a un conjunto de funciones de IMS estándar a
través de las APIs DL/I y Java database connectivity (JDBC).
5.3.1 IMS Database Manager (IMS DM)
El IMS DB es un sistema de gestión de bases de datos que ayuda a organizar los datos
de negocio tanto con independencia de programas como de dispositivo.
En el corazón del IMS DB están las bases de datos jerárquicas y el lenguaje de
manipulación de datos (llamadas DL/I). Los datos dentro de las bases de datos se
IBM Corporation
21/02/2011
73 de 131
organizan en una estructura de árbol, con datos en cada nivel de la jerarquía
relacionados con, y en algunos dependientes de, los datos en el nivel más alto de la
jerarquía. La siguiente figura muestra un modelo de bases de datos jerárquico. El dato
se almacena en la base de datos sólo una vez. Cada elemento de datos está disponible
para cualquier usuario que esté autorizado a utilizarlo. Los usuarios no tienen que tener
copias personales de los datos.
Modelo de base de datos jerárquica.
Con el IMS DB se puede:
Mantener la integridad de los datos. Los datos en cada base de datos se garantiza que
están consistentes y que permanecen en ella aunque el IMS DB no esté funcionando.
Disponer de un punto de control centralizado y de acceso a los datos IMS que se
procesan por las aplicaciones IMS.
Ejecutar consultas contra los datos en la base de datos.
Ejecutar transacciones de bases de datos (inserciones, actualizaciones y borrados)
como una única unidad de trabajo, de manera que la transacción o se complete entera
o no.
Ejecutar múltiples transacciones de bases de datos concurrentemente con los
resultados de cada transacción mantenidos aislados de las otras.
Mantener las bases de datos. El IMS DB proporciona facilidades para afinar las bases
de datos mediante la reorganización de las mismas.
A los datos en IMS DB se puede acceder desde las aplicaciones que se ejecutan en:
•
IMS TM
•
CICS Transaction Server
IBM Corporation
21/02/2011
74 de 131
•
Trabajos batch en el z/OS
•
WAS for z/OS
•
Procedimientos almacenados en DB2 UDB for z/OS.
5.3.2 IMS Transaction Manager
El IMS TSM es un gestor transaccional basado en mensajes.
Una transacción es un conjunto de datos de entrada que disparan la ejecución de un
programa de aplicación (proceso o trabajo) de negocio. El mensaje que dispara el
programa de aplicación y el retorno de cualquier resultado, se considera una
transacción.
La palabra terminal se usa a lo largo de esta sección para describir a los dispositivos y
a los controladores. Los terminales de operación pueden ser impresoras, estaciones de
trabajo, terminales de comunicación, o una mezcla de estos dispositivos.
El IMS TM proporciona servicios para:
•
Procesar mensajes de entrada recibidos desde una variedad de fuentes (como
la red de terminales, otros sistemas IMS, la web, …).
•
Procesar mensajes de salida creados por los programas de aplicación.
•
Proporcionar un mecanismo de encolamientos para gestionar estos mensajes.
•
Proporcionar procesamiento de transacciones de alto volumen, alto rendimiento,
alta capacidad y bajo coste tanto para las bases de datos jerárquicas del IMS
DB como para las relacionales de DB2.
El IMS TM soporta muchas sesiones de terminal a volúmenes transaccionales muy
altos. Los usuarios de las sesiones de terminal pueden ser:
•
Personas en terminales o estaciones de trabajo.
•
Otros programas de aplicación, o en el mismo sistema z/OS, en otros sistemas
z/OS, o en plataformas no z/OS.
Se puede definir una variedad de opciones de procesamiento online, Por ejemplo, se
pueden definir transacciones para aplicaciones de entrada de datos de alto volumen,
otras para aplicaciones interactivas, y otras para soportar consultas predefinidas.
5.3.3 Servicios de sistema IMS
Estos proporcionan los siguientes servicios tanto para el IMS DB como para el IMS TM:
•
De integridad de los datos.
•
De rearranque y recuperación después de fallos.
•
De seguridad, para controlar el acceso y modificación de los recursos IMS.
•
De gestión de los programas de aplicación, despachando trabajo, cargando
programas de aplicación, y proporcionando servicios de bloqueo.
•
De diagnóstico y recolección de información de rendimiento.
IBM Corporation
21/02/2011
75 de 131
•
De operación de IMS.
•
De comunicación para que otros sistemas del z/OS se hablen con el IMS.
Los servicios se proporcionan mediante:
•
Comandos IMS.
•
Programas de utilidad proporcionados con el IMS.
•
Exits de usuario.
•
Definiciones de servicios.
IMS y z/OS
El IMS es una gran aplicación que se ejecuta en z/OS. Tanto uno como otro está
diseñados para hacer el mejor uso posible de los componentes de software y hardware
del sistema.
El IMS dentro del z/OS utiliza diferentes espacios de direcciones: uno de control, varios
espacios de direcciones separados que proporcionan servicios IMS, y varios espacios
de direcciones que ejecutan programas de aplicación. A estos espacios de direcciones
a veces se les llama regiones5, como la región de control del IMS.
Vamos a ver los distintos componentes de un sistema IMS en la siguiente sección:
5.3.4 Estructura de los subsistemas IMS
La sección describe los distintos tipos de espacios de direcciones z/OS con sus
interrelaciones.
La región de control es el centro del subsistema IMS y se ejecuta en un espacio de
direcciones. Cada región de control usa muchos otros espacios de direcciones que
proporcionan servicios adicionales a la región de control, y en las que se ejecutan los
programas de aplicación del IMS. Algunas aplicaciones y utilidades IMS se ejecutan en
regiones separadas llamadas regiones batch; éstas últimas están separadas del
subsistema IMS, de su región de control y sin conexión con él.
Cada uno de los entornos IMS es una combinación diferente de hardware y programas
que soportan objetivos de procesamiento diferenciados. Los cuatro entornos IMS son:
•
DB/DC, que tiene toda la funcionalidad tanto del IMS TM como del IMS DB
•
DBCTL que sólo contiene la funcionalidad del IMS DB
•
DCCTL, que sólo contiene la funcionalidad del IMS TM
•
Batch, que contiene la funcionalidad del IMS DB, pero que sólo se usa para
trabajos batch.
El entorno DB/DC tiene instalado tanto el IMS TM como el IMS DB y por tanto dispone
de toda la funcionalidad del producto. Sus principales objetivos son:
5
El concepto de región se originó en el sistema operativo MVT (Multiprogramming with Variable
Number of Tasks), un precursor del z/OS
IBM Corporation
21/02/2011
76 de 131
•
Permitir a los usuarios de terminal obtener datos y actualizar bases de datos en
tiempo real con un buen rendimiento
•
Asegurar que los datos que se obtienen son los actuales
•
Distribuir procesamiento transaccional entre diferentes procesadores en una red
de comunicaciones
•
Ejecutar programas de aplicación batch que actualizan bases de datos a
determinados intervalos
•
Ejecutar utilidades de bases de datos en batch
La región de control permite acceso a:
•
La red, que podría incluir una consola del sistema operativo, terminales,
servidores web, etc.
•
Colas de mensajes IMS para aplicaciones IMS que se ejecuten en regiones de
mensajes (MPRs, Message Processing Regions) o regiones de mensajes Java
•
Librerías del IMS
•
Logs del IMS
•
Bases de datos Fast Path
•
Espacios de direcciones separados de DL/I
•
Región DBRC (Database Recovery Control)
•
Región IFP (IMS Fast Path)
•
Región JBP (Java batch processing program)
•
Región BMP (Batch message processing program)
Múltiples sistemas IMS
Se pueden ejecutar varios sistemas IMS en una imagen z/OS única o en varias
imágenes de sistema operativo. Se llama sistema IMS al conjunto de región de control y
todas las regiones dependientes asociadas. Un sistema batch IMS (por ejemplo, batch
DB) también se considera un sistema IMS.
Hay tres formas de ejecutar varios subsistemas IMS en diferentes imágenes z/OS:
•
Multiple Systems Coupling (MSC): MSC solo soporta conexiones IMS-IMS.
•
Inter System Communications (ISC): Es más flexible porque
conexiones a IMS como a otros productos z/OS como CICS.
•
Parallel Sysplex: Ejecutar varios subsistemas IMS en un entorno de Parallel
Sysplez es una buena manera de balancear carga, proporcionar escalabilidad a
los sistemas, y poder tener máxima disponibilidad. Se pueden compartir colas
de mensajes y bases de datos.
IBM Corporation
21/02/2011
soporta tanto
77 de 131
En las relación del IMS con otros elementos del z/OS, conviene destacar que
proporciona soporte a aplicaciones TCP/IP a través de la función OTMA explicada
anteriormente. También soporta APPC, una implementación del protocolo LU 6.2 que
permite distribuir aplicaciones por una red y comunicarse con ellas independientemente
del hardware donde residan.
5.4 WAS
WebSphere Application Server (WAS) es un servidor de aplicaciones basado en
tecnología J2EE y de Web Services. Es un entorno de despliegue y de ejecución de
aplicaciones Java construidas con tecnologías basadas en estándares abiertos, que
soporta la mayoría de las funciones como servlets, Java Server pages (JSPs), y
Enterprise Java Beans (EJBs) e incluye la última tecnología de interfaces e integración
de servicios.
WebSphere Application Server proporciona la capa de la lógica de aplicación en una
arquitectura de tres niveles, lo que permite a los componentes de cliente interactuar con
los recursos de datos y las aplicaciones legacy. Estos niveles son niveles lógicos.
Puede que se estén ejecutando o no en el mismo servidor físico.
Figura n+12: arquitectura de aplicación de tres niveles
La responsabilidad de la presentación y la interacción con el usuario reside en los
componentes del primer nivel. Estos componentes de cliente permiten al usuario
interactuar con los procesos del segundo nivel de forma segura e intuitiva.
Los clientes no acceden directamente a los servicios del tercer nivel. Por ejemplo, un
componente de cliente proporciona un formulario en el que el cliente solicita los
productos. El componente de cliente entrega este pedido a los procesos del segundo
nivel, que comprueban las bases de datos del producto y realizan las tareas que son
necesarias para la facturación y el envío.
Los procesos del segundo nivel se conocen normalmente como la capa de la lógica de
aplicación. Estos procesos gestionan la lógica empresarial de la aplicación y pueden
acceder a los servicios del tercer nivel. La capa de la lógica de aplicación es donde se
ejecuta la mayor parte del trabajo de los procesos. Varios componentes de cliente
pueden acceder simultáneamente a los procesos del segundo nivel, por lo que esta
capa de la lógica de aplicación debe gestionar sus propias transacciones.
IBM Corporation
21/02/2011
78 de 131
En el ejemplo anterior, si varios clientes intentan realizar un pedido del mismo artículo,
del que sólo queda uno, la capa de la lógica de aplicación debe determinar quién tiene
derecho a ese artículo, actualizar la base de datos para reflejar la compra e informar a
los otros clientes de que el artículo ya no está disponible.
La base de datos establece su propio control de accesos, normalmente bloqueando un
registro que se está procesando.
Pero cuando se hace ese bloqueo si es cuando un artículo se coloca en un carro de
compra, para evitar que los demás clientes consideren la posibilidad de compra o es
cuando la compra se hace efectiva, es una decisión de negocio y la toma el segundo
nivel.
La separación del segundo y el tercer nivel reduce la carga en los servicios del tercer
nivel, da soporte a una gestión de conexiones más eficaz y puede mejorar el
rendimiento general de la red.
Los servicios del tercer nivel están protegidos del acceso directo de los componentes
de cliente que residen en una red segura. La interacción debe producirse a través de
los procesos del segundo nivel.
La ventaja de z/OS es la posibilidad de desplegar el segundo y el tercer nivel en un
entorno físico de z/OS, conservando la seguridad y las ventajas lógicas de los sistemas
de nivel único.
El WAS en z/OS está altamente integrado con todas las características y servicios
ofrecidos por el sistema operativo. Puede interactuar con todos los subsistemas del
z/OS como el DB2, el CICS y el IMS, y tiene atributos para seguridad, rendimiento,
escalabilidad y recuperación, además de estar perfectamente integrado con el
componente de gestión de carga WLM.
Hay dos clases de espacios de direcciones en el WAS de z/OS, la región de control y la
servidora. Una región de control ejecuta programas autorizados de sistema y gestiona
tareas como las comunicaciones del servidor; una región servidora es el espacio de
direcciones equivalente al servidor en una plataforma distribuida y ejecuta las
aplicaciones Java a través de los containers EJB y web. Una instancia de servidor de
aplicación se compone de una región de control (CR) y de una o más regiones
servidoras (SRs). Véase la siguiente figura:
Figura n+13: una instancia de servidor de aplicaciones
El servidor de aplicaciones en z/OS soporta dos tipos de configuración: base y network
deployment. Cada configuración usa la misma jerarquía arquitectural compuesta de
servidores, nodos y celdas.
IBM Corporation
21/02/2011
79 de 131
Un servidor es el componente de runtime primario. Es donde se ejecuta realmente la
aplicación. Proporciona contenedores y servicios que se especializan en permitir la
ejecución de los componentes específicos de la aplicación Java. Cada servidor de
aplicaciones corre en su propia máquina virtual java (JVM). Dependiendo de la
configuración, los servidores podrían trabajar separadamente o en combinación:
•
Configuración base: cada servidor de aplicaciones funciona como una entidad
separada. No hay distribuciones de cargas de trabajo o administración común
entre los servidores de aplicación.
•
Configuración de network deployment: múltiples servidores de aplicación se
mantienen desde un punto de administración central. Además, se pueden
montar los servidores de aplicación en cluster para la distribución de las cargas
de trabajo.
Un nodo es una agrupación lógica de procesos de servidor gestionada por WebSphere
que comparte configuración y control. Un nodo se asocia generalmente con la
instalación física de un servidor de aplicaciones. Conforme nos movemos a
configuraciones de servidor de aplicaciones más complejas, se introducen los
conceptos de configuración de diferentes nodos desde un servidor de administración
común o la distribución de cargas de trabajo entre nodos. En estas configuraciones
gestionadas de forma centralizada, cada nodo tiene un agente.
Una celda es una agrupación de nodos en un dominio administrativo. En la
configuración base, una celda contiene un nodo. Ese nodo puede tener varios
servidores, pero los ficheros de configuración de cada servidor se almacenan y
mantienen individualmente. En la configuración de network deployment, una celda
puede constar de varios nodos, todos administrados desde un único punto. Los ficheros
de aplicación y configuración para todos los nodos en la celda se centralizan en el
repositorio de configuración maestra de la celda. Conviene aclarar el concepto de
container; es el que permite la separación de los distintos elementos en tiempo de
ejecución. Así un container de EJB se usa para ejecutar EJBs. Otro, conocido como
Web container, se usa para ejecutar elementos relacionados con web como HTML,
servlets y JSPs. Juntos configuran el runtime del servidor de aplicaciones dentro de la
JVM.
Veamos en más detalle las dos configuraciones de WAS en z/OS que se han citado
anteriormente:
5.4.1 Nodo de servidor base de aplicaciones:
Esta configuración se corresponde con la estructura operacional más sencilla de WAS
en z/OS. Consta de un servidor de aplicación y un servidor de demonio (un nodo y una
celda), como puede verse en la siguiente figura. Todos los ficheros de configuración y
las definiciones se guardan en una estructura de directorios del sistema de ficheros
creada para este servidor de aplicaciones base. El servidor de demonio es un servidor
especial con una región de control. Hay un servidor de demonio por celda por sistema
(o LPAR). Cada nodo de servidor base de aplicaciones contiene la administración de su
propio dominio de celda y un repositorio separado para su configuración. Por tanto, se
puede disponer de muchos servidores base de aplicación, unos aislados de otros,
teniendo todos sus propias políticas de administración para sus necesidades
específicas de negocio.
IBM Corporation
21/02/2011
80 de 131
Nodo de servidor base de aplicaciones
5.4.2 Network Deployment Manager:
Es una extensión del servidor base de aplicaciones. Permite administrar múltiples
servidores de aplicación desde un punto centralizado. Aquí, los servidores de aplicación
se atachean a nodos, y varios nodos pertenecen a una celda. Con el Deployment
Manager se pueden administrar fácilmente sistemas que escalan en horizontal o en
vertical, así como aplicaciones distribuidas. El Deployment Manager también gestiona
los repositorios de cada nodo, pudiendo realizar tareas como crear, mantener y eliminar
los mismos.
Network Deployment Manager
IBM Corporation
21/02/2011
81 de 131
En la siguiente figura se puede ver una instancia del servidor de aplicaciones.
Repasemos sus principales componentes:
IBM Corporation
21/02/2011
82 de 131
Componentes de una instancia de WAS
Servidores de aplicaciones: un servidor de aplicaciones es una máquina virtual Java
(JVM) que ejecuta aplicaciones de usuario. Los servidores de aplicaciones utilizan la
tecnología Java para ampliar las posibilidades del servidor Web para manejar
peticiones de aplicaciones Web. Con un servidor de aplicaciones, un servidor puede
generar una respuesta dinámica y personalizada a una petición de un cliente.
Servidores Web. En el producto WAS, un servidor de aplicaciones trabaja en
colaboración con un servidor Web para manejar las peticiones de aplicaciones Web. El
servidor de aplicaciones y el servidor Web se comunican utilizando un plug-in HTTP del
servidor Web.
Servidores JMS. Motor de mensajería. El producto da soporte a la mensajería al
proporcionar un proveedor de JMS (Java Message Service).
Un contenedor Web es un entorno de ejecución para aplicaciones web. Procesa
servlets, JSPs y otros tipos de componentes del lado servidor.
Un contenedor de EJBs proporciona un entorno de ejecución para los beans de
empresa del servidor de aplicaciones. El contenedor maneja todos los aspectos de una
operación de bean de empresa dentro del servidor de aplicaciones y actúa como
intermediario entre la lógica de empresa escrita por el usuario en el bean y el resto del
entorno del servidor de aplicaciones.
IBM Corporation
21/02/2011
83 de 131
Los servicios JCA permiten la conexión de los servidores de aplicación a los
Enterprise Information Systems (EIS); en definitiva es la tecnología Java para acceso a
sistemas legacy (incluyendo las bases de datos).
Los principales conectores son:
•
CICS Transaction Gateway (CTG): el conector proporciona la interfaz entre el
Java y las transacciones CICS. Es un conjunto de componentes cliente y
servidor que incorpora los servicios y facilidades para acceder a CICS desde el
servidor de aplicaciones.
•
IMS Connect: es un servidor-conector que permite a un cliente desde el servidor
de aplicaciones intercambiar mensajes con el IMS Open Transaction Manager
Access (OTMA).
•
JDBC: API que se usa desde el lenguaje Java para acceder a datos en
sistemas de gestión de bases de datos relacionales, e incluso jerárquicos (IMS).
Esta interfaz ni cae necesariamente en la categoría de conector porque no
requiere un espacio de direcciones separado. La implementación de la interfaz
la proporciona cada proveedor de bases de datos como un “driver”; éste
proporciona la portabilidad porque todos los accesos JDBC se hacen a través
de llamadas estándar con parámetros estándar.
En WAS se soporta obviamente el uso de web services. A las tecnologías clave sobre
las que se desarrollan y despliegan estos, WAS añade otras como un registro de UDDI
privado o un Framework para invocación de aquéllos (WSIF).
La gestión de cargas de trabajo se lleva a cabo con la ayuda del WLM del z/OS y
permite optimizar la distribución de las peticiones entrantes entre los servidores de
aplicación, EJBs, servlets u otros objetos. Se pueden balancear cargas de acuerdo a
las capacidades de los diferentes servidores del complejo sysplex, se pueden disponer
de capacidades de gestión de fallos mediante el redireccionamiento de peticiones si
uno o más servidores no son capaces de procesarlas y se puede crecer (y decrecer) el
número de regiones servidoras dependiendo de la carga en cada momento.
La seguridad tanto de los recursos J2EE como administrativos comprende los
diferentes elementos de autenticación, control de acceso, integridad de datos,
confidencialidad, privacidad e interoperabilidad.
Se basa en estándares de la industria y tiene una arquitectura abierta que le asegura
una conectividad e interoperabilidad segura con diferentes EIS como DB2, CICS, IMS,
MQ y Domino. También soporta proveedores de seguridad externos como RACF, TAM
(Policy Director) o proxies inversos como WebSEAL.
La administración del sistema se compone de:
•
Una consola administrativa que es una interfaz gráfica que proporciona
muchas funciones de guía para tareas de despliegue y administrativas.
•
El cliente de scripting (wsadmin): el programa de scripting es un entorno no
gráfico intérprete de comandos muy potente que permite realizar operaciones
administrativas en entornos productivos y de forma desasistida.
•
Programas de administración (Java Management Extensions): el producto
soporta una interfaz de programación Java para desarrollar programas de
administración. Todas las herramientas administrativas que se suministran con
IBM Corporation
21/02/2011
84 de 131
el producto están escritas de acuerdo al API, que se basa en la especificación
JMX estándar de la industria.
•
Herramientas de línea de comandos: son programas que se ejecutan desde
una línea de comandos del sistema operativo y que permiten ejecutar tareas
específicas, en contraposición con la administración de propósito general. Se
pueden emplear para arrancar y parar servidores de aplicación, comprobar el
estado de servidores, o añadir o eliminar nodos, etc.
•
Ficheros de configuración: los datos de configuración del producto residen en
ficheros XML que se gestionan a través de las herramientas mencionadas
anteriormente.
Dentro del apartado de rendimiento, se encuentra el de monitorización del sistema y las
aplicaciones, y que permite recolectar y analizar los datos relativos al comportamiento
de aquéllos. Estas herramientas de monitorización incluyen:
Performance Monitoring Infrastructure (PMI).- Es la infraestructura clave para la
monitorización de WebSphere Application Server y del resto de productos de la familia
WebSphere. Los datos de rendimiento proporcionados por PMI ayudar a monitorizar y a
hacer tuning del rendimiento del servidor de aplicaciones.
Tivoli Performance Viewer (TPV).- que permite analizar los datos de PMI.
A diferencia del tuning para rendimiento, que se focaliza en resolver problemas
asociados con procesos que van lentos o que no están optimizados, la determinación
de problemas se centra en encontrar soluciones a problemas funcionales. En este
sentido podemos recurrir a visualizadores de class loader para diagnosticar problemas
en este componente, o de dumps y log de errores, pasando por documentación de
diagnóstico que describe técnicas de depuración disponibles para ayudar a resolver
problemas con Java.
IBM Corporation
21/02/2011
85 de 131
5.5 MQ
Muchas grandes organizaciones hoy tienen legados de sistemas de IT de varios
proveedores, y que a menudo dificultan la compartición de datos. Muchas de estas
organizaciones también necesitan comunicarse y compartir datos electrónicamente con
proveedores y clientes – que podrían a su vez tener otros sistemas diferentes. Sería útil
disponer de una herramienta que gestione mensajes que podría recibir de otro tipo de
sistema y enviar a otro diferente.
El software IBM WebSphere MQ facilita la integración de aplicaciones mediante el paso
de mensajes entre aplicaciones y servicios web. Se usa en docenas de plataformas
hardware y para mensajería punto a punto desde aplicaciones Java, C, C++ y COBOL.
Tres cuartas partes de las empresas que compran sistemas de mensajería entre
aplicaciones compran WebSphere MQ.
Las colas de mensajes y el software que las gestiona, como IBM WebSphere MQ for
z/OS, permiten la comunicación programa a programa. En el contexto de las
aplicaciones online, la mensajería y el encolamiento se deben entender tal y como
sigue:
•
Mensajería significa que hay programas que se comunican enviándose
mensajes (datos) entre ellos, en lugar de llamándose entre ellos de forma
directa.
•
Encolamiento significa que los mensajes se dejan en colas en memoria, de
manera que los programas pueden ejecutarse independientemente unos de
otros, a diferentes velocidades y en diferentes momentos, en distintas
localizaciones, y sin tener una conexión lógica entre ellos.
En la siguiente figura puede observarse un mecanismo básico de comunicación
programa a programa utilizando un modelo de comunicación síncrono.
El programa A prepara un mensaje y lo pone en una cola 1. El programa B recoge el
mensaje de la cola 1 y lo procesa. Tanto el programa A como el B usan un API para
poner mensajes en la cola y recoger mensajes de la cola. Al API del WebSphere MQ se
le llama Message Queue Interface (MQI).
Cuando el programa A pone un mensaje en la cola 1, el programa B puede no estar
ejecutándose. La cola almacena el mensaje de forma segura hasta que el programa B
arranca y está listo para obtener el mensaje. Del mismo modo, en el momento en el que
el programa B obtiene el mensaje de la cola 1, el programa A puede no estar ya
ejecutándose. Con este modelo, no existe el requerimiento de que los dos programa
estén ejecutándose a la vez para que se puedan comunicar.
Hay un claro problema de diseño sobre cuánto tiempo el programa A debería esperar
antes de continuar con su ejecución. Este diseño podría ser deseable en algunas
situaciones, pero no cuando las esperas son muy prolongadas. Para gestionar estas
situaciones, es para lo que se diseña la comunicación asíncrona.
IBM Corporation
21/02/2011
86 de 131
Figura n+17: modelo de diseño de aplicación síncrono
Usando un modelo asíncrono, el programa A pone mensajes en la cola 1 para que los
procese el programa B, aunque es el programa C, actuando asíncronamente con
respecto al programa A, el que obtiene las respuestas de la cola 2 y las procesa.
Típicamente, el programa A y el programa C serían parte de la misma aplicación.
Puede verse este flujo de actividad en la siguiente figura.
El modelo asíncrono es natural para WebSphere MQ. El programa A puede continuar
poniendo mensajes en la cola 1 y no se bloquea teniendo que esperar una respuesta a
cada mensaje. Puede continuar poniendo mensajes en la cola 1 incluso si el programa
B falla. Si así ocurre, la cola 1 almacena los mensaje de forma segura hasta que el
programa B rearranque.
En una variación del modelo asíncrono, el programa A podría poner una secuencia de
mensajes en la cola 1, opcionalmente continuar con algún otro procesamiento, y luego
volver a recoger y procesar las respuestas. A esta propiedad del WebSphere MQ en el
que las aplicaciones que se comunican no tienen que estar activas al mismo tiempo, se
le conoce como “independencia del tiempo”.
IBM Corporation
21/02/2011
87 de 131
Figura n+18: modelo de diseño de aplicación asíncrono
5.5.1 Tipos de mensajes
WebSphere MQ usa cuatro tipos de mensajes:
•
Datagrama: un mensaje para el que no se espera respuesta.
•
Petición: un mensaje para el que se espera respuesta.
•
Respuesta: una respuesta a un mensaje de petición.
•
Informe: un mensaje que describe un evento como la ocurrencia de un error o
una confirmación de llegada.
Una cola de mensajes se usa para almacenar mensajes enviados por los programas.
Se definen como objetos pertenecientes al gestor de colas.
Cuando una aplicación pone un mensaje en una cola, el gestor de colas se asegura de
que el mensaje:
IBM Corporation
21/02/2011
88 de 131
•
se almacene de forma segura.
•
sea recuperable.
•
se entregue una vez, y sólo una ve a la aplicación que lo recibe.
Esto es cierto incluso aunque el mensaje se entregue a la cola desde otro gestor de
colas; a esto se le conoce como la propiedad de entrega asegurada del WebSphere
MQ.
5.5.2 Gestor de Colas
El componente de software que posee y gestiona las colas se llama gestor de colas
(queue manager, QM). En WebSphere MQ, el gestor de la cola de mensajes se llama
MQM, y proporciona los servicios de mensajería a las aplicaciones, asegura que los
mensajes se ponen en la cola correcta, enruta mensajes a otros gestores de colas, y
procesa mensajes a través de la interfaz común de programación llama Message
Queue Interface (MQI).
El gestor de colas puede retener mensajes para procesamiento futuro en el caso de
indisponibilidades de aplicación o de sistema. Los mensajes se retienen en una cola
hasta que se recibe una respuesta satisfactoria a través de MQI.
Hay similitudes entre los gestores de colas y los de bases de datos. Aquéllos poseen y
controlan colas de forma similar a cómo los gestores de bases de datos poseen y
controlan sus objetos de datos. Proporciona una interfaz de programación para acceder
a los datos, y facilidades de administración, seguridad, autorización y recuperación.
Sin embargo, hay también diferencias significativas. Las bases de datos se diseñan
para proporcionar almacenamiento de datos de larga duración con unos mecanismos
de búsqueda muy sofisticados, mientras que las colas no están diseñadas de esa
manera. Un mensaje en una cola indica por lo general que un proceso de negocio está
incompleto. Podría representar una petición no satisfecha, una respuesta que no se ha
procesado, o un informe sin leer.
5.5.3 Tipos de colas de mensajes
Existen diferentes tipos de colas de mensajes. Los más relevantes son los siguientes:
•
Cola local.- Una cola es local es aquella poseída por el gestor de colas al que
se conecta el programa de aplicación. Se usa para almacenar mensajes para
los programas que usan el mismo gestor de colas. El programa de aplicación no
tiene porque ejecutarse en la misma máquina que el servidor de colas.
•
Cola remota.- Una cola es remota si la posee un gestor de colas diferente. Una
cola remota no es una cola real; sólo es la definición de una cola remota al
gestor de colas local. Los programas no pueden leer mensajes de una cola
remota. Las colas remotas se asocian a una cola de transmisión.
•
Cola de transmisión.- Esta cola local tiene un propósito especial; se usa como
un paso intermedio cuando se envían mensajes a colas poseídas por un gestor
de colas remoto. Estas colas son transparentes a la aplicación porque se usan
internamente por la cola de iniciación del gestor de colas. Es a una cola local a
la que el gestor de colas escribe (transparentemente al programador) un
IBM Corporation
21/02/2011
89 de 131
mensaje disparador (trigger) cuando se cumplen ciertas condiciones en otra
cola local, por ejemplo, cuando se pone un mensaje en una cola de mensajes
vacía o en un cola de transmisión. Dos aplicaciones WebSphere MQ
monitorizan las colas de iniciación y leen mensajes disparadores, el monitor de
disparadores y el iniciador de canal. El primero puede arrancar aplicaciones,
dependiendo del mensaje, y el segundo arranca la transmisión entre gestores
de colas.
•
Cola de no entregados (dead-letter).-Un gestor de colas debe poder gestionar
situaciones cuando no puede entregar un mensaje, por ejemplo:
o
La cola de destino está llena
o
La cola de destino no existe
o
Las altas de mensajes en la cola de destino se han inhabilitado
o
El que envía no está autorizado a usar la cola de destino
o
El mensaje contiene un número de secuencia de mensaje duplicado
Cuando ocurre una de estas condiciones, el mensaje se escribe a la cola de no
entregados. Esta cola se define cuando se crea el gestor de colas, y cada gestor de
colas tiene una. Se usa como depositario de todos los mensajes que no se pueden
entregar.
5.5.4 ¿Qué es un canal?
Un canal es un enlace de comunicación lógico. El estilo conversacional de la
comunicación programa a programa requiere la existencia de una conexión de
comunicaciones entre cada par de aplicaciones que se comunican. Los canales aíslan a
las aplicaciones de los protocolos de comunicaciones que están por debajo.
WebSphere MQ usa dos tipos diferentes de canales:
•
Canal de mensaje: es el que conecta a dos gestores de colas a través de
agentes del canal de mensajes (MCAs). Es unidireccional, compuesto por dos
agentes de canal de mensajes (un emisor y un receptor) y un protocolo de
comunicaciones. Un MCA transfiere mensajes desde una cola de transmisión a
un enlace de comunicaciones, y de un enlace de comunicaciones a una cola
destino. Para comunicaciones bidireccionales, es necesario definir un par de
canales con emisor y receptor.
•
Canal MQI: conecta a un cliente MQ a un gestor de colas. Los clientes no tienen
un gestor de colas de su propiedad. Es bidireccional.
5.5.5 ¿Cómo queda asegurada la integridad transaccional?
Un negocio podría requerir que a dos o más bases de datos distribuidas se mantuvieran
sincronizadas. MQ ofrece una solución que a su vez supone que muchas unidades de
trabajo actúen asíncronamente (como puede verse en la siguiente figura).
IBM Corporation
21/02/2011
90 de 131
Figura n+19: modelo de diseño de aplicación asíncrono
La parte de arriba de la figura muestra una estructura de two-phase commit, mientras
que la solución WebSphere MQ se presenta en la mitad de abajo:
La primera aplicación escribe en una base de datos, pone un mensaje en una cola, y
emite un syncpoint para confirmar los cambios a los dos recursos. El mensaje contiene
datos que se usan para actualizar una segunda base de datos en un sistema separado.
Cuando se confirma la unidad de trabajo, se hace disponible el mensaje para obtenerlo
con un MCA.
En la segunda unidad de trabajo, el MCA que envía obtiene el mensaje de la cola de
transmisión y lo envía al MCA que recibe en el sistema con la segunda base de datos, y
el MCA que recibe coloca el mensaje en la cola de destino. Todo esto se lleva a cabo
de forma fiable gracias a la propiedad de entrega asegurada de WebSphere MQ.
Cuando se confirma una unidad de trabajo, el mensaje queda disponible para que se
obtenga por parte de la segunda aplicación.
En la tercera unidad de trabajo, la segundo aplicación obtiene el mensaje desde la cola
de destino.
Es la integridad transaccional de las unidades de trabajo 1 y 3 y la entrega garantizada
del WebSphere empleada en la unidad de trabajo 2, los que asegurar la integridad de la
transacción de negocio completa. Si la transacción de negocio es más compleja, habrá
muchas unidades de trabajo involucradas.
IBM Corporation
21/02/2011
91 de 131
5.5.6 Un ejemplo de mensajería y encolamiento
Veamos con un ejemplo de agencia de viajes las facilidades de mensajería jugando el
papel de reserva de unas vacaciones. Asumamos que el agente de viajes debe reservar
un vuelo, una habitación de hotel, y un coche de alquiler. Todas estas reservas deben ir
bien antes de que la transacción de negocio completa se dé por completada.
Con un gestor de colas como WebSphere MQ,la aplicación puede enviar varios
peticiones a la vez; no necesita esperar por una respuesta a una petición antes de
enviar la siguiente. Se coloca un mensaje en cada una de las tres colas, sirviendo la
aplicación de reservas de vuelos, la de reservas de hotel y la de alquiler de coches.
Cada aplicación entonces puede llevar a cabo su tarea respectiva en paralelo con las
otras dos y colocar un mensaje de respuesta en la cola de respuesta. La aplicación del
agente espera a estas respuestas y genera una respuesta consolidada al agente de
viajes.
Aunque la aplicación podría procesar normalmente las respuestas sólo cuando se
hubieran recibido todas, la lógica del programa puede especificar qué hacer también
cuando sólo se reciben conjuntos parciales de respuestas en un determinado periodo
de tiempo.
Figura n+20: proceso paralelo
IBM Corporation
21/02/2011
92 de 131
5.5.7 Interfaz con CICS, IMS, Batch, o TSO/E
WebSphere MQ está disponible en una amplia variedad de plataformas. WebSphere
MQ for z/OS incluye algunos adaptadores que proporcionan soporte de mensajería y
encolamiento para:
•
CICS – el bridge WebSphere MQ-CICS
•
IMS – el bridge WebSphere MQ-IMS
•
Batch o TSO
5.6 Middleware Bases de Datos
Dado que ya se aprovechó la sección del IMS dentro del capítulo de middleware
transaccional para detallar las características del IMS DB, este capítulo lo dedicaremos
en exclusividad a DB2, sistema gestor de bases de datos relacional por excelencia en
z/OS. Al final del capítulo podrá verse un resumen del VSAM, método de acceso y
organización de ficheros tradicional del entorno operativo, y que actualmente sigue
soportando parte tanto de la información de los clientes, como de los propios
subsistemas del z/OS.
5.6.1 DB2
Una base de datos proporciona el almacenamiento y el control de los datos del negocio.
Es independiente de una o más aplicaciones. Si está bien diseñada y desplegada, la
base de datos debería proporciona una vista única y consistente de los datos, así que
se puede controlar y gestionar de forma centralizada.
Una manera de describir la visión lógica de esta colección de datos es usar un modelo
de entidad-relación. La base de datos almacena los detalles (atributos) de elementos
particulares (entidades) y las relaciones entre los diferentes tipos de entidades. Por
ejemplo, para la aplicación de control de stock, se deberían tener Piezas, Pedidos de
Compra, Clientes y Pedidos de Clientes (entidades). Cada entidad tendría atributos, así
por ejemplo la Pieza tendría el Número de Pieza, el Nombre, el Precio Unitario, la
Cantidad,
Estas entidades también tendrían relaciones entre ellas, por ejemplo un cliente se
relacionaría con los pedidos que hace, y que a su vez se relacionaría con las piezas
que han sido ordenadas. La siguiente figura muestra un modelo de entidad-relación.
IBM Corporation
21/02/2011
93 de 131
Entidades, Atributos y Relaciones
Un sistema de gestión de base de datos, como el componente IMS DB o el DB2,
proporciona un método para almacenar y usar los datos de negocio en la base de
datos. Se dan facilidades a los usuarios del sistema para que lleven a cabo distintos
tipos de operaciones en el propio sistema como son la manipulación de los datos en la
base de datos o la gestión de la propia estructura de la base de datos.
Los sistemas de gestión de bases de datos (DBMSs) se categorizan de acuerdo a sus
estructuras de datos. Hay diferentes tipos de bases de datos que pueden usarse en el
mainframe para explotar el z/OS, listas invertidas, jerárquicas, en red, o relacionales. En
contraposición a la navegación por la estructura de la base de datos jerárquicas, en el
caso de las bases de datos relacionales (RDBMS) el acceso se lleva a cabo nombrando
las estructuras de datos y poniendo condiciones de búsqueda a los atributos de
aquéllas.
5.6.1.1
¿Qué estructuras existen en una base de datos relacional?.
La base de datos (database): es una agrupación lógica de datos. Contiene un
conjunto de espacios de tablas y de índices relacionados. Una base de datos,
típicamente, contiene todo el dato asociado con una aplicación o grupo de aplicaciones
relacionadas.
Tabla: Es una estructura lógica compuesta por filas y columnas. Las filas no tienen un
orden predeterminado, y si se leen los datos podrían necesitar ordenarse. El orden de
las columnas es el que se especifica cuando se crea la tabla por parte del
administrador. En la intersección de cada columna y fila hay un elemento de datos
específico que se llama valor, o más precisamente, valor atómico. A una tabla se le
nombra por un calificador de alto nivel del usuario propietario seguido del nombre de la
tabla. Hay tres tipos de tablas:
•
Tabla base que se crea explícitamente y contiene datos persistentes.
•
Tabla temporal que almacena resultados intermedios de consultas.
•
Tabla de resultados que se devuelve cuando se consultas las tablas.
Ejemplo de una tabla
IBM Corporation
21/02/2011
94 de 131
En la figura anterior puede verse un ejemplo de tabla donde,
•
El conjunto ordenado de columnas son DEPTO, DEPTNAME, MGRNO y
ADMRDEPT. Todos los datos de una determinada columna deben ser del
mismo tipo.
•
Cada fila contiene datos para un determinado departamento.
•
En la intersección de una columna y una fila hay un valor. Por ejemplo,
PLANNING es el valor de la columna DEPTNAME en la fila del departamento
B01.
Índices: un índice es un conjunto ordenado de apuntadores a filas de una tabla. A
diferencia de las filas de una tabla que no están en un orden específico, un índice se
mantiene siempre en orden por el DB2. Un índice se usa para dos propósitos:
•
Para rendimiento con el fin de recuperar valores de datos de forma rápida.
•
Para unicidad.
Creando un índice por el nombre del empleado se pueden obtener los datos más
rápidamente para un empleado que leyendo la tabla entera. También creando un índice
único por número de empleado, el DB2 fuerza la unicidad de cada valor.
Claves: es una o más columnas que se identifican como tales en la creación de una
tabla o índice, o en la definición de la integridad referencial.
•
Clave primaria: una tabla sólo puede tener una clave primaria porque es la que
define a la entidad. Deben cumplir dos condiciones:
o
Debe tener valor; no se admiten valores nulos.
o
El valor debe ser único; debe tener un índice único definido sobre ella.
•
Clave única: sabemos que la clave única debe ser única, pero es posible que
tengamos más de una clave única en una tabla. En el caso de una tabla de
empleados, tanto el número de empleado como su identificación fiscal son
atributos que definen claves únicas. Para asegurar que sean claves únicas se
definen sobre ellas índices únicos.
•
Clave ajena: es una clave que se especifica en una restricción de integridad
referencial haciendo su existencia dependiente de una clave primaria o única
(clave padre) en otra tabla (o en la misma). En una tabla de empleados, el
departamento en el que trabaja un empleado debe existir en la tabla de
departamentos. Esta constricción es parte de la definición de la tabla.
Antes vimos algunas estructuras básicas comunes a los RDBMS. Ahora, veamos
algunas estructuras de datos específicas de DB2.
Vistas: una vista es una forma alternativa de ver los datos en una o más tablas. Es
como un marco que ponemos a una tabla para que sólo se puedan ver parte de los
datos de la tabla. Por ejemplo, se puede crear una vista sobre la tabla de
departamentos para permitir que los usuarios sólo tengan acceso a un determinado
departamento y actualicen información de salarios; no se desea que puedan ver los
salarios de otros departamentos. Las vistas también se pueden usar para simplificar
conjuntas complejas a usuarios menos experimentados.
IBM Corporation
21/02/2011
95 de 131
Espacio de tablas: una tabla se sólo una construcción lógica. Se guarda en un fichero
físico llamado espacio de tablas. Pueden contener una o más tablas. Se nombra
usando el nombre de la base de datos seguido por el nombre del espacio de tablas.
Hay tres tipos de espacios de tablas: simples, segmentados y particionados. El DB2
utiliza ficheros VSAM para sus espacios de tablas.
Index space: es otra estructura de almacenamiento que contiene un solo índice. De
hecho, cuando se crea un índice, el DB2 automáticamente define un espacio de
índices.
Grupos de almacenamiento: un grupo de almacenamiento consta de un conjunto de
volúmenes en disco (DASD) que contienen los ficheros en los que se han almacenado
tablas e índices.
En la siguiente figura pueden verse los objetos que hemos estado describiendo
anteriormente:
Jerarquía de objetos en un subsistema DB2
Si nos centramos en estructuras de esquemas, el DB2 proporciona:
UDT (User-Defined Data Type) – es una forma de que los usuarios definan sus propios
tipos de datos por encima de los tipos de datos habituales de tipos alfanumérico y
numéricos.
UDF (User-Defined Function) – se puede definer sobre una función DB2 existente y
puede asimilarse a un programa de aplicación que se accedería por una sentencia
SQL.
IBM Corporation
21/02/2011
96 de 131
Trigger (disparador. gatillo) – define una serie de acciones que se ejecutan cuando se
lleva a cabo una inserción, actualización o borrado en una tabla determinada.
Large Object (LOB) – es un tipo de dato que usa el DB2 para gestionar datos no
estructurados. Hay tres tipos:
•
Binary Large Objects (BLOBs) – se usan para imágenes, audios y videos.
•
Character Large Objects (CLOBs) – se usan para grandes documentos de
textos.
•
Double Byte Character Large Objects (DBCLOBs) – se usan para almacenar
grandes documentos de texto escritos en idionas que requieren caracteres de
doble byte como el Kanji.
Los LOBs se almacenan en tablas auxiliares especiales apuntadas desde la tabla base
y que usan un espacio de tablas de LOB especial.
Procedimiento almacenado – es un programa de aplicación escrito por el usuario que
se almacena y ejecuta típicamente en el servidor. Diseñados específicamente para el
entorno cliente servidor, donde desde aquél se hace una llamada a éste para ejecutar el
procedimiento almacenado, y que a su vez accede a los datos en DB2 y devuelve los
resultados. Se puede asimilar a un programa de aplicación que se define al DB2 y lo
gestiona el subsistema DB2.
Nos queda explicar un poco cuáles son y para que sirven las estructuras del sistema
DB2; son las siguientes:
Catálogo y directorio – el DB2 mantiene él mismo un conjunto de tablas que contienen
metadatos sobre los objetos DB2 del subsistema. El catálogo guarda información sobre
todos los objetos, tales como tablas, vistas, índices, espacios de tablas, etc. El
directorio guarda información sobre los programas de aplicación. El catálogo puede
consultarse para ver información de los objetos; el directorio no se puede consultar.
Cuando se crea una tabla de usuario, el DB2 automáticamente guarda el nombre, el
creador, su espacio de tablas y la base de datos en el catálogo y pone esta información
en una tabla del catálogo llamada SYSIBM.SYSTABLES. Todas las columnas definidas
en la tabla se guardan automáticamente en la tabla SYSIBM.SYSCOLUMNS. Además,
para guardar que el propietario de la tabla tiene autorización sobre la misma, se inserta
automáticamente una fila en SYSIBM.SYSTABAUTH. Cualquier índice que se cree
sobre la tabla se guardaría en la tabla de catálogo SYSIBM.SYSINDEXES.
Buffer Pools – son áreas de memoria virtual en las que el DB2 almacena
temporalmente páginas de los espacios de tablas e índices. Actúan como un área de
cache entre el DB2 y el almacenamiento físico en disco donde residen los datos. La
página de datos se obtiene del disco y se ubica en una página del buffer pool. Si el dato
que se necesita ya está en un buffer, se evita un acceso (I/O) al disco.
Log activo y archivo – el DB2 guarda todos los cambios a los datos y otros eventos
significativos en un log. Esta información se usa para recuperar los datos en el caso de
un fallo, o para que se puedan echar los cambios hacia atrás hasta un punto anterior en
el tiempo. El DB2 escribe cada registro de log en un fichero que se llama log activo.
Cuando el log activo se llena, el DB2 copia los contenidos a un fichero en disco o en
cinta que se llama log archivo. Un fichero de bootstrap lleva la cuenta de estos ficheros
de log activos y archivos. El DB2 usa esta información en escenarios de recuperación,
para rearranques del sistema, o para cualquier actividad que requiere leer el log.
IBM Corporation
21/02/2011
97 de 131
5.6.1.2
Espacios de direcciones del DB2
DB2 necesita al menos tres espacios de direcciones, el de servicios de sistema
(MSTR), el de servicios de bases de datos (DBM1) y el de gestión de los bloqueos
(IRLM). Además podría desplegarse el Distributed Data Facility (DDF) que se usa para
comunicarse con otros subsistemas DB2. Véase la siguiente figura:
El DB2 es un subsistema z/OS multi-espacio de direcciones
Una parte muy importante del subsistema DB2 es el conjunto de las utilidades cuya
función es que el administrador de la base de datos pueda mantener los objetos.
Se ejecutan a través de trabajos batch (jobs) que están a su vez en librerías de ficheros
propiedad del administrador. Sin embargo, hay herramientas que generar el JCL del
trabajo como es el caso de Administration Tool o la opción Utility del panel de DB2
interactivo (DB2I).
Podrían dividirse en las siguientes categorías:
Utilidades de organización de los datos – después de creadas las tablas, el DBA
emplea la utilidad de LOAD para poblarlas, con la posibilidad de comprimir grandes
volúmenes de datos. La utilidad UNLOAD o el programa ensamblador DSNTIAUL
permiten al administrador mover o copiar datos entre subsistemas. Es posible mantener
los datos en un cierto orden gracias a la utilidad de reorganización, REORG.
Inserciones y cargas sucesivas pueden alterar ese orden, y es cuando el DBA planifica
REORGs en base a los informes de la utilidad de RUNSTATS que proporciona
información de estadísticas y rendimiento. Se pueden pasar estadísticas incluso sobre
los catálogos de los sistemas.
Utilidades de copia y recuperación – es fundamental que el DBA tome copias imagen
de los datos e índices con la utilidad COPY. Las copias pueden ser completas o
incrementales. Como las recuperaciones sólo pueden hacerse a copias completas, se
recurre a la utilidad MERGECOPY para mergear copias incrementales con una
completa La utilidad RECOVER durante una recuperación a un punto anterior en el
tiempo, permite volver la tabla a una copia imagen. Más a menudo, se emplea el
recuperar una tabla a situación actual, echando mano en primer lugar a una copia
imagen, y aplicando el conjunto de cambios que figuren en el log. Sin una copia
imagen, un índice se puede recrear a través de la utilidad REBUILD INDEX.
IBM Corporation
21/02/2011
98 de 131
Utilidades de consistencia de datos – una de las utilidades básicas de consistencia de
datos es CHECK, que puede usarse para comprobar y ayudar a corregir integridad
referencial e inconsistencias, especialmente después de una carga masiva o de una
recuperación. Un uso típico de las utilidades es ejecutar un RUNSTATS, luego un
EXPLAIN, y después otra vez un RUNSTATS.
Tanto el administrador del sistema como el DBA utilizan comandos DB2 para
monitorizar el subsistema. Tanto el panel de DB2I como la Administration Tool
proporcionan la facilidad de entrar comandos DB2. El comando –DISPLAY DATABASE
muestra el estado de los espacios de tablas y de los índices de una determinada base
de datos. –DISPLAY UTILITY presenta el estado de una utilidad. También hay
comandos para mostrar el estado del buffer pool, de las conexiones a DB2 y de la
información de los logs.
El Structured Query Language (SQL) es un lenguaje de alto nivel que se usa para
especificar qué información necesita un usuario sin tener que saber cómo obtener el
resultado. El SGBDR es el responsable de desarrollar el camino de acceso necesario
para devolver los datos de la consulta del usuario. Se usa sobre una o más tablas y
devuelve el resultado como una tabla de resultados.
El SQL se subdivide en tres categorías de acuerdo a la funcionalidad que tienen:
•
DML – lenguaje de manipulación de datos que se usa para leer y modificar
datos.
•
DDL – lenguaje de definición de datos que se usa para definir, cambiar y borrar
objetos DB2.
•
DCL – lenguaje de control de datos que se usa para conceder y revocar
autorizaciones.
Hay varias herramientas que pueden emplearse para entrar sentencias SQL:
SPUFI, que significa SQL Processing Using File Input. Es parte del panel de DB2I. Lo
utilizan muy a menudo los administradores de bases de datos. Permitir escribir y
guardar una o más sentencias SQL a la vez. El DBA lo usa para conceder y revocar
autorizaciones; a veces, cuando es una petición urgente, también se emplea para crear
objetos. También lo emplean los desarrolladores para probar consultas.
QMF, que significa Query Management Facility. Permite entrar y salvar sólo una
sentencia a la vez. La facilidad principal del QMF es la del reporting; permite diseñar
formatos de informe flexibles y reusables, incluyendo gráficos.
5.6.1.3
Programación de aplicaciones en DB2
El SQL es un estándar de lenguaje de acceso a las bases de datos relacionales
necesario para acceder y manipular datos en una base de datos DB2. Se puede usar o
dinámicamente con un programa que interprete como el SPUFI, o puede estar
embebido y compilado, o ensamblado, con un lenguaje de programación.
¿Cómo se escriben las aplicaciones que acceden a datos DB2?: para hacerlo el SQL se
embebe en el código fuente de un lenguaje de programación, como Java, REXX, C,
C++, COBOL, Fortran, PLI/I o high-level Assembler. Hay dos categorías de sentencias
SQL que pueden usarse en un programa: las estáticas y las dinámicas.
SQL estático: se refiere a sentencias SQL que se escriben en el código fuente. En el
proceso de preparación del programa, el DB2 desarrolla los caminos de acceso para las
sentencias, y éstos se guardan en DB2. El SQL no cambia de ejecución a ejecución,
usándose los caminos de acceso siempre sin que el DB2 tenga que crearlos de nuevo,
IBM Corporation
21/02/2011
99 de 131
un proceso que causa overhead (no todas las sentencias SQL deben tener un camino
de acceso).
SQL dinámico: se refiere a sentencias SQL que son parcial o totalmente desconocidas
cuando se escribe el programa. Sólo cuando se ejecuta el programa, el DB2 sabe
cuáles son las sentencias y es capaz de determinar los mejores caminos de acceso.
Estos no se guardan porque pueden cambiar de una ejecución a otra. Un ejemplo de
esto es el SPUFI. Este es realmente un programa de aplicación que acepta sentencias
SQL dinámicas. Son las que se entran en el fichero de entrada. Cada vez que se usa el
SPUFI, el SQL puede cambiar, por lo que se embeben en el programa sentencias de
preparación de SQL especiales para gestionar esto.
IBM Corporation
21/02/2011
100 de 131
5.7 SW de gestión
La gestión de sistemas se encarga de la gestión tradicional de la la infraesructura . Para
sistemas z/OS existen diferentes áreas de especialización que en su conjunto forman la
gestión de sistemas. Estas áreas son:
•
Operaciones z/OS gestión de los eventos mainframe centralizada. De ello se
encargan los operadores de consola y los especialistas en la automatización del
sistema.
•
Explotación z/OS: Planificación de los trabajos, Gestión del almacenamiento,
Gestión del batch (Ucls y salidas).
•
Servicios de soporte técnico: monitorización específica de dominios, diagnóstico
y gestión de incidentes, análisis de capacidad, estudio de tendencias, análisis
de rendimiento y uso. Este trabajo afecta a los técnicos de sistemas, analístas
de aplicaciones, administradores de base de datos, administradores de
almacenamiento o técnicos de comunicaciones.
•
Seguridad: auditoría y control de acceso a los recursos. El administrador de
seguridad sería el responsible.
5.7.1 Gestión de almacenamiento
El sistema operativo z/OS dispone de una gestión de almacenamiento que hace mas
fácil las funciones de este tipo de gestión:
•
Asignación de espacio de almacenamiento con límites y controles dependiendo
de quien lo pide, el entorno donde se pide, etc…
•
Liberación de espacio no usado o caducado
•
Salvaguarda y recuperación de los datos mediante backups.
•
En el apartadoa 4.1.5 existe una descripción de estas funciones.
5.7.2 Gestión de la operación (Tivoli SA y Netview)
El objetivo de las operaciones z/OS es mantener el más alto grado de disponibilidad de
los sistemas z/OS. Para lograr este objetivo es crítico tener control sobre las redes de
comunicación en el z/OS, y poder automatizar acciones correctivas en caso de detectar
perdidas de disponibilidad. Es asimismo importante una gestión de eventos centralizada
mainframe donde se observe no solo situaciones de indisponibilidad sino situaciones de
degradación del servicio para poder actuar preventivamente antes de sufrir pérdidas de
disponibilidad.
Estas dos funciones las proporciona el Tivoli Netview for z/OS y la aplicación específica
de operación Tivoli System automation
5.7.2.1
Disponibilidad de red
Tivoli NetView for z/OS proporciona funciones que ayudan a mantener el grado más
alto de disponibilidad de las redes del System z. Ofrece un conjunto amplio de
herramientas para gestionar y mantener redes y sistemas complejos desde un único
IBM Corporation
21/02/2011
101 de 131
punto de control. Porporciona funciones de correlación avanzada para automatizar
cualquier evento de red o de sistema, soportanto tanto redes SNA como TCP/IP.
La gestión de redes IP con Netview incluye:
•
Gestión de SNA sobre IP usando la tecnología Enterprise Extender
•
Soporte de dynamic virtual IP addresses (DVIPA)
•
Descubrimiento recursos IP y correlación de topología
•
Gestión de conexiones: tanto activas como históricas
•
Trazas de paquetes y formateo a nivel de pila y de Open Systems Adapter
(OSA): ayudan en el diagnóstico de problemas
•
Soporte de comandos desde la linea de comandos de Netview o desde
procedimientos REXX u otras rutinas de automatización. * Soporte servidor IP:
funciones de REXEC, RSH, Syslogd
•
Respuesta automática a intrusiones: junto con las funcionalidades del
Communication Server de detectar intrusiones, el Netview automatiza acciones
como el envio de notificaciones, o la recogida de información.
•
Eventos: incluyendo traps SNMP, alertas y mensajes, eventos EIF (event
integration facility), eventos con especificación CBE (common base event).
•
Soporte de IP versión 6
•
Network address translation
•
Seguridad: previene conexiones no autorizadas al Netview, protege direcciones
IP de comandos.
Las capacidades como motor de automatización incluyen:
•
Automatización de respuesta a mensajes y eventos y correlación de los mismos
•
Revisión (Parsing) de mensajes y comandos
•
Comandos de temporarización
•
Autotareas: reciben mensajes y lanzan comandos
•
Exits de instalación: rutinas de usuario que pueden modificar el comportamiento
del Netview.
5.7.2.2
Automatización del sistema con Tivoli System Automation
Tivoli System Automation for z/OS (SA z/OS) es una aplicación basada en Netview
diseñada para proporcionar un punto de control único para un amplio espectro de
funciones de gestión de sistemas. Es una pieza clave en la automatización. Sus
funciones principales son ver, controlar y automatizar un gran número de elementos del
sistema desde hadware hasta software. Entre sus funciones destacan:
IBM Corporation
21/02/2011
102 de 131
•
Monitorización de recursos que afectan al usuario final: monitoriza componentes
hardware, monitoriza aplicaciones y productos software, monitoriza procesos
automáticos y monitoriza mensajes y alertas.
•
Toma de acciones: arranca y para todo el sistema (Inicia secuencias de
arranque y parada de hardware y software), gestiona operaciones remotas y
locales en un Parallel Sysplex , gestiona diferentes sistemas operativos (z/OS,
OS/390®, MVS™, VM, VSE, y Linux for zSeries) , controla la coupling facility ,
reacciona a errores y eventos no planificados.
•
Automatiza tareas repetitivas y complejas: inicia y para recursos software, inicia
y para recursos hardware, controla canales y channel paths, controla
disponibilidad de dispositivos de E/S, controla el switching de los puertos de los
dispositivos de E/S, detecta y responde a mensajes del sistema, realiza el initial
program load (IPL) ,realiza el system power-on reset (POR), construye las
políticas de automatización del sistema y da soporte a rutinas de usuario para
aumentar la potencia de la automatización.
5.7.2.3
Gestión del Sysplex.
Tivoli SA gestiona el Sysplex a traves de sus capacidades de monitorización y control
de recursos de sistema y de Sysplex tales como CFs, imagenes z/OS, pilas TCP/IP,
interfaces IP, CPs, LPARs, etc…
Para ello utiliza las siguientes capacidades:
•
Descubrimiento, usando XCF, del estado operativo de todos los Netview en el
Sysplex lo que permite la alta disponibilidad del Netvie
•
Monitorización del Sysplex y de los recursos del sistema usando una
combinación de monitorización por muestreo y monitorización por evento
•
Integración en el Tivoli Enterprise Portal
Existe además una aplicación basada en Tivoli SA específica para suministrar Alta
Disponibilidad a dos o mas sistemas z/OS y zLinux asegurando asimismo la integridad
de los datos.
Esta tecnología es el GDPS y ya fue descrita en capítulos anteriores.
5.7.3 Gestión del Batch
En z/OS hay dos tipos de carga Online y Batch. Así como la carga Online se planifica
globalmente y se gestiona con el WLM, la carga Batch requiere una planificación
relativamente fija, lo que la hace especialmente apropiada para el uso de una
herramienta ejecute esta planificación liberando a los operadores de esta tarea
repetitiva.
El Tivoli Workload Scheduler es el planificador de IBM y permite gestionar la mayor
parte de las dependencias a las que esta sometido un trabajo Batch:
•
De un Hardware específico, por ejemplo tipos de cartucho.
•
De la presencia o no de Monitores transaccionales o de BBDD. Por ejemplo un
proceso batch que deba ser submitido despues de parar el CICS.
•
De recursos del sistema operativo, tales como los iniciadores del JES2/3.
IBM Corporation
21/02/2011
103 de 131
•
De la finalización (correcta o incorrecta) de otros trabajos.
•
De parámetros variables que pueden ser cambiados en cada ejecución.
•
De parámetros de tiempo. De la hora del día, del día de la semana o del año.
Algunos jobs tienen que ser ejecutados los Viernes. Algunas veces hay reglas
complejas para saber cuando un día es de vacaciones.
Cuando se usa el Tivoli Workload Scheduler for z/OS para lanzar los trabajos batch,
estas dependencias se definen en una base de datos por un administrador.
Este crea un plan a largo plazo (long-term plan LTP). En este plan se especifican las
ejecuciones de cada aplicación así como sus depedencias.
Ademas, cada día se crea un plan diario (current plan CP). Este es un plan detallado
que tiene en cuenta las dependencias anteriores y es el que finalmente se ejecuta.
5.7.4 Monitorización y rendimiento
5.7.4.1
SMF (System Management Facility)
En un entorno multitarea es importante recojer información acerca del comportamiento
del sistema y de las diferentes cargas de trabajo que se ejecutan en el mismo.
Los components del z/OS y los subsistemas, recojen datos estadísticos y se lo pasan al
SMF que lo guarda en sus ficheros.
Hay mas de 100 tipos distintos de registros SMF y contienen información acerca del uso
de CPU, de la actividad de ficheros, del uso de la CF, de actividades de I/O de arranque
de sistemas, de uso de DB2, de uso de WAS, etc….
Estos registros SMF una vez tratados con los correspondientes generadores de
informes, se usan para tareas que van desde la planificación de las necesidades futures
de capacidad hasta la detección de problemas o cuellos de botella en discos, pasando
por el perfil de los tiempos de acceso a una estructura de la CF a lo largo del día.
5.7.4.2
RMF
RMF es un producto especializado en el análisis del uso de los recursos y en como
estan siendo utilizados de acuerdo con los objetivos de rendimiento de los distintos
tipos de carga.
Ayuda a monitorizar y vigilar el rendimiento y detector y analizar problemas en ese area.
Tambien se usa para obtener perfiles de carga y es la base para los estudios de
crecimiento.
Con el RMF, se puede:
Determinar si el sistema esta funcionando adecuadament
Detectar cuellos de botella producidos por contención de recursos
Evaluar el servicio que se está dando
Detectar problemas tanto en el sistema como en las aplicaciones
IBM Corporation
21/02/2011
104 de 131
Tiene components Online, componentes de recogida de datos (que almacena el SMF)
y un componente Post-Procesos.
Se suele hablar de tres monitores RMF:
Monitor I Recoge datos para el análisis a largo plazo. Esta continuamente activo y
graba registros resumiendo la información a intervalos especificados. El valor por
defecto es de 15 minutos.
Monitor II Hace una ‘foto’ del sistema en ese instante. Recoge datos acerca del estado
de los AS y de la utilización de los recursos.
Monitor III Recoge datos para el análisis a corto plazo. Es un monitor enfocado
principalmente al estudio de los retrasos en ejecución y su causa. Aunque también tiene
datos de uso de recursos.
5.7.4.3
Tivoli Omegamon
Además del RMF, los monitores Omegamon,proporcionan métricas en tiempo real,
pasado reciente e histórico que sirven para generar eventos y ayudar en el diagnóstico
de problemas. Se integran con la automatización para la resolución automática de la
degradación del servicio y son fuente de información para las herramientas de
generación de informes. Los monitores que IBM proporciona son:
Tivoli OMEGAMON XE for z/OS: monitorización sistema operativo z/OS
Tivoli OMEGAMON XE for CICS: monitorización del CICS
Tivoli OMEGAMON XE for IMS: monitorización del IMS
Tivoli OMEGAMON XE for DB2 Performace Expert: monitorización del DB2
Tivoli OMEGAMON XE for Mainframe Networks: monitorización TCP/IP y SNA
Tivoli OMEGAMON XE for Messaging: monitorización de WebSphere MQ y WebSphere
Message Broker
Tivoli OMEGAMON XE for Storage: monitorización de almacenamiento
Tivoli Advanced Catalog Management: monitorización catálogos
Tivoli Advanced Audit for DFSMShsm: monitorización de auditorías de ficheros de
control del HSM
Tivoli Advanced Reporting for DFSMShsm: monitorización HSM
Tivoli Advanced Backup and Recovery: monitorización conformidad normativa de copias
de seguridad.
Tivoli Tape Optimizer: monitorización copiado cintas del RMM.
Tivoli Composiste Application Manager for Application Diagnostics: monitorización de
WebSphere Application Server
Tivoli Composite Application Manager for SOA: monitorización de servicios web
Tivoli Composite Application Manager for Transactions: monitorización transacciones
multiplataforma.
IBM Corporation
21/02/2011
105 de 131
Tivoli OMEGAMON DE: para generar paneles de control multidominio
5.7.4.3.1 Tivoli Enterprise Portal como interface de monitorización
Los distintos monitores OMEGAMON, se integran utilizando el Enterprise Portal como
Interface de monitorización.
Permite establecer umbrales de rendimiento, generar y enviar comandos, adaptar los
informes a las necesidades concreta y permite visualizar tanto el pasado reciente como
el histórico.
Este sería un ejemplo de Enterprise Portal
Además, el IBM Tivoli Enterprise Portal, debido a su función integradora de información,
permite ver diferentes segmentos de la compañía en una única ventana. Proporciona un
punto de control único para gestionar los recursos que usan las aplicaciones críticas de
negocio, incluyendo una gran variedad de sistemas operativos, servidores, bases de
datos, mainframes, y componentes web.
A continuación algunos detalles sobre los componentes mas comunes
5.7.4.3.2 Monitorización de z/OS con Tivoli OMEGAMON XE for z/OS
Con el Tivoli OMEGAMON XE on z/OS se puede realizar un análisis detallado de forma
rápida y sencilla de cada uno de los elementos que componen el sistemas z/OS,
Sysplex Paralelo, z/OS incluyendo los Unix System Services. Se puede comprobar y
optimizar el Workload Manager, a nivel de servicios y recursos. Y desde una sola
pantalla, se puede obtener múltiples vistas de las operaciones del sistema y sus
iteraciones con otros componentes simplificando de esta manera enormemente la
gestión del entorno.
Proporciona información detallada acerca de uso de CPU de los espacios de
direcciones, análisis de cuellos de botellas (incluyendo E/S y detalles de encolamiento),
IBM Corporation
21/02/2011
106 de 131
channel paths, estructuras en la coupling facility, cross-system coupling facility (XCF),
DASD, enclaves, enqueues, sistemas global resource serialization (GRS) ring , análisis
de impacto, LPARs, alertas de operador, paginación, uso de real storage y virtual
storage, clases de servicios, utilización de CPU del sistema, cintas, WLM, USS, tiempo
de respuesta de usuario.
5.7.4.3.3 Monitorización de CICS con Tivoli OMEGAMON XE for CICS
Tivoli OMEGAMON XE for CICS gestiona proactivamente los sistemas CICS,
incluyendo CICSPlex para alcanzar el mejor rendimiento, y evitar caídas o pérdidas de
servicio.
Sus funciones principales son:
Gestionar el rendimiento y disponibilidad del CICS TS y CICS TG
Rastrear el flujo de la transacción integrado con Tivoli Composite Application Manager
Identificar tareas esperando a recursos, y señalar tiempos de espera excesivos para
resolver problemas rápidamente
5.7.4.3.4 Monitorización de DB2 con Tivoli OMEGAMON XE for DB2
Tivoli OMEGAMON XE for DB2 ayuda a analizar la eficiencia del DB2 y optimizar su
rendimiento
Monitoriza, analiza y optimiza el rendimiento de DB2
Identificación fácil y rápida de cuellos de botellas gracias a reglas predefinidas
Combina informes en batch con monitorización en tiempo real e información histórica
Guarda datos de rendimiento para explotarlos con herramientas de análisis.
5.7.4.3.5 Monitorización de la transacción con Tivoli Composite Application Manager
for Transactions
IBM Tivoli Composite Application Manager for Transactions (ITCAM for Transactions)
ofrece un completo sistema de gestión de seguimiento de transacciones completo y
unificado que se ejecuta en una sola infraestructura consolidada. Puesto que el
aislamiento de problemas en los complejos entornos actuales de IT puede llevar horas
o días y puede suponer una pérdida de tiempo y de beneficios y un deterioro de la
satisfacción del cliente, ITCAM for Transactions proporciona una solución para aislar
componentes del problema y agilizar el diagnóstico y la restauración del servicio antes
de que un impacto negativo en el cliente afecte directamente a los beneficios.
Sus principales componentes son:
Internet Service Monitoring, que proporciona las herramientas para identificar
problemas de disponibilidad y de tiempo de respuesta y supervisa para probar la
disponibilidad y el rendimiento de distintos servicios de Internet, que incluyen sitios web
de supervisión, aplicaciones e-Commerce basadas en la web y correo electrónico (así
como los servicios subyacentes, como DNS, LDAP y SMTP en los que se basan estos
servicios).
Response Time, que se centra en la experiencia del usuario final, tanto real como
simulada, supervisando transacciones web, reproduciendo scripts grabados y
IBM Corporation
21/02/2011
107 de 131
experiencias de escritorio de usuarios reales. Response Time incluye los componentes
siguientes:
Application Management Console y Editor de configuración de gestión de aplicaciones
Transaction Tracking, que ofrece una vista completa de tiempos de respuesta del
sistema para ayudar a aislar rápidamente la causa de los problemas de tiempo de
respuesta y de disponibilidad. Transaction Tracking incluye los siguientes componentes:
Transaction Collector
Transaction Reporter
También dispone de componentes que permiten su utilización con, prácticamente,
cualquier infraestructura SW.
IBM Corporation
21/02/2011
108 de 131
6 Integración en los modelos IT más usados
en la actualidad
6.1 SOA
6.1.1 Introducción
El objetivo principal de este capítulo no es definir la arquitectura orientada a
servicios (SOA) u otros términos relacionados con él, sino para aclarar el papel del
Mainframe en un mundo centrado en SOA. La inclinación natural para muchos es
suponer que sólo afecta a los sistemas SOA distribuidos y la tecnología que es
inferior a cinco años de edad! Sin embargo, esto está lejos de la verdad.
El Mainframe del siglo 21 puede remontar sus orígenes a los ordenadores
System/360 de mediados de la década de 1960. Uno de los puntos clave del diseño
del System/360 fue implementar una arquitectura de computadores que escala dentro
de la familia a lo largo de continuas actualizaciones sin perder la compatibilidad
hacia atrás de las aplicaciones. El compromiso de IBM con este nivel de
compatibilidad se ha mantenido desde entonces. Debido a esta compatibilidad con
versiones anteriores, muchos programas que fueron escritos hace décadas todavía se
pueden ejecutar en los actuales sistemas Mainframe de IBM. Esto ha proporcionado
un importante valor empresarial para nuestros clientes, ya que les ha permitido
proteger la inversión en sus aplicaciones.
Sin embargo, cuando el mundo ha adoptado las nuevas tecnologías y arquitecturas,
esto ha planteado un problema: ¿cómo liberar el poder de estos activos de la empresa
en las arquitecturas de computación nuevas que han surgido en los últimos años?
Este reto se inició con la Arquitectura Cliente / Servidor de la década de 1990, y ha
continuado hasta hoy. SOA es simplemente una extensión de ese desafío.
6.1.2 Estándares en SOA
Afortunadamente, SOA posee un atributo clave que posiciona el Mainframe como un
participante de pleno derecho. En la página Web de IBM developerWorks se refiere
a los siguientes atributos de SOA:
La interfaz se define en una forma neutra que debe ser independiente de la
plataforma de hardware, el sistema operativo y el lenguaje de programación en la
que se lleva a cabo el servicio.
Los estándares son críticos para SOA, y específicamente para la participación de
entornos heterogéneos, la realidad actual, en la arquitectura SOA. A través de la
normalización de las interfaces entre los servicios, ahora es posible para todos los
fabricantes (como IBM) incorporar estas normas en los sistemas de procesamiento de
transacciones y los sistemas de gestión de base de datos para que las aplicaciones
existentes se puedan integrar fácilmente en un entorno SOA. Hay una serie de
normas que permiten esta interacción, pudiéndose destacar las siguientes:
IBM Corporation
21/02/2011
109 de 131
Servicios de Web - Una de las normas más importantes que surgieron en los últimos
diez años es el SOAP. SOAP define un formato común XML para describir las
llamadas de servicio y los mensajes de intercambio de los servicios invocados. SOAP
es un protocolo simple basado en XML para las aplicaciones de intercambio de
información a través de HTTP o mensajería middleware. La aparición de SOAP
como un estándar de transporte ha contribuido a que los proveedores puedan habilitar
SOAP sus subsistemas para hacer más fácil para los servicios de interactuar. El
protocolo de transporte HTTP es relativamente ubicuo, y como resultado, los
mensajes SOAP se pueden pasar entre las plataformas de computación,
proporcionando la neutralidad del Sistema Operativo que se describe en la definición
de SOA. Más adelante en este trabajo se presentan detalles acerca de cómo el
software de la plataforma z ha implementado SOAP y otros interfaces estándares
para facilitar los servicios Web que llaman a las operaciones del Mainframe y sus
datos.
XML - XML no es una nueva tecnología, ha estado en uso durante más de
cinco años. Es fundamental para la interoperabilidad necesaria entre los
servicios en SOA. El carácter de independencia de las descripciones XML,
junto con el gran número de utilidades que lo procesan, lo convierten en un
formato de representación de datos ideal para la información que fluye en las
invocaciones de servicio. Esta generalización se extiende a la plataforma
System z, donde el procesamiento de XML es posible en los nuevos
servidores de aplicaciones, como la tecnología WebSphere Application
Server (WAS) y en los tradicionales como CICS, IMS. Los compiladores de
COBOL y PL/I incluyen el soporte de XML.
Middleware orientado a mensajes – La mensajería ha existido desde hace
muchos años, proporcionando un mecanismo fiable, y de transporte rápido,
para pasar datos entre aplicaciones. Muchos clientes han empleado IBM
WebSphere MQ (MQSeries ®) como el transporte para llamar a funciones
remotas en sistemas separados, al igual que lo hace SOAP. De hecho,
WebSphere MQ se puede utilizar como el transporte base para SOAP.
WebSphere MQ de IBM (WMQ) está presente en el negocio de muchos
clientes de IBM en todo el mundo, y esta penetración ha ayudado a hacer
WMQ un estándar de facto para las aplicaciones de comunicaciones
programa a programa.
SOA no es sólo los servicios Web. Una arquitectura orientada a servicios se pueden
implementar sin necesidad de utilizar los servicios Web, aunque esto sea poco
común. SOA simplemente debe basarse en hardware con un sistema operativo y un
transporte de lenguaje que de manera neutra faciliten la comunicación entre los
servicios. En el caso de IBM System z, WebSphere Message Broker es un
componente clave de la infraestructura SOA de muchos clientes. Su implementación
en la plataforma System z facilita el transporte e intermediación de los servicios con
las características de escalabilidad y resiliencia de esta plataforma.
6.1.3
Construyendo las TI con nuevos parámetros
El objetivo de SOA es conseguir que las aplicaciones sigan agilidad y flexibilidad que exige
el negocio y uno de los caminos es abordar la modernización de las aplicaciones. Los retos
IBM Corporation
21/02/2011
110 de 131
para la modernización de aplicaciones, en términos generales, se pueden categorizar en
tres áreas:
Maleabilidad de las aplicaciones existentes: Muchas de las aplicaciones en z/OS,
especialmente aquellas aplicaciones que no han sido escritas pensando en su
reutilización, se clasifican como lo que la industria denomina aplicaciones
monolíticas. Estas aplicaciones suelen estar fuertemente
cohesionadas e incurren en altos costos de mantenimiento y mejora
(aproximadamente un 70% del presupuesto de TI de una organización se gasta en
mantenimiento). Aunque estas aplicaciones incorporan un gran conocimiento del
negocio, son difíciles de cambiar con la finalidad de cumplir con los nuevos
requisitos de negocio. A menudo, esta dificultad en replanteamiento de las
aplicaciones conduce a tomar decisiones sobre si se deben reescribir las
aplicaciones para hacer su extensión más flexible y fácil. Pero la reescritura podría
no ser siempre la mejor opción, si tenemos en cuenta la cantidad de código
involucrado, de las repercusiones en las interdependencias, y del dilema de la
selección de plataforma para evitar el envejecimiento de las nuevas aplicaciones.
Extensibilidad y capacidad de los conocimientos: Tenemos tres retos concretos
en el ámbito de los conocimientos.
o
Uno de ellos es que los desarrolladores suelen estar especializados en
un entorno determinado, y sus habilidades no son portables a través de
diferentes proyectos ya que proyecto está a menudo asociado a una
plataforma (por ejemplo, los desarrolladores de CICS no crean
programas Web y los desarrolladores Web no crean aplicaciones para
CICS). También utilizan diferentes procesos, herramientas y lenguajes
de programación.
o
El segundo reto es el coste y el tiempo necesario para adaptar al
personal existente a las nuevas tecnologías.
o
El tercer desafío es que los "baby boomers", la gente que puede
manejar las
plataformas de aplicaciones existentes, están
desapareciendo. No pueden ser sustituidos por las nuevas
generaciones ya que no entienden o no tienen interés en las antiguas
tecnologías y esto obliga a los administradores de TI a considerar la
contratación externa, la estabilización, el final de la vida de las
aplicaciones, la vuelta a escribirlas, y así sucesivamente. Todas estas
opciones son difíciles y costosos. El desarrollo de software es lento,
repetitivo y propenso a errores. Muchos aplicaciones existentes están
escritas en RPG, COBOL, PL / I, 4GL, etc. Las nuevas aplicaciones
requieren Java, Java Enterprise Edition, y otras habilidades
relacionadas con la Web 2.0. El paradigma de desarrollo, por lo general,
diferencia entre los lenguajes existentes orientados procedimiento en
comparación con los lenguajes orientados a objetos (por ejemplo; Java).
Muchas veces, la reconversión profesional de un programador de
COBOL para convertirse en programador de Java puede no ser una
opción, debido a los altos costos asociados con la reconversión y la
posibilidad de que el programador de COBOL falle en esta reconversión.
Multitud de plataformas y de middleware: Las fusiones y adquisiciones
incrementan la necesidad de información comercial y presenta un desafío
único que ahora tiene que hacer frente a plataformas y middleware dispares
y heterogéneos. Estas consolidaciones podrían dar lugar a una
fragmentación de los conocimientos necesarios para apoyar estas
plataformas y añadir complejidad de las interfaces entre las aplicaciones.
Todo ello tiende a frenar el desarrollo de las funciones necesarias. Estos
desafíos que a menudo se traducen en altos costos, reducen la capacidad
IBM Corporation
21/02/2011
111 de 131
de responder de forma rápida a los requisitos del negocio y a ofrecer
soluciones alternativas de lo que el equipo de desarrollo es capaz de realizar
en lugar de aquellas otras soluciones que reclama Negocio.
6.1.4
Mejores prácticas SOA
En general, el primer paso es realizar una planificación adecuada para identificar los
servicios correctos como primer paso. Para esto, quizás sea útil considerar el uso de
metodologías, como el de Modelado de Componentes de Negocio (CBM) o la de Modelado
de la Arquitectura Orientad a Servicios.(SOMA). Es importante señalar que no todos los
componentes, módulos o interfaces de un programa tienen que convertirse en un servicio.
También es necesario considerar las tecnologías que faciliten la gestión y utilización de
servicios, tales como Enterprise Service Bus (ESB) y los procesos de coreografía.
Por último, pero no menos importante, se debe abordar el gobierno de OA. En un entorno
orientado a la reutilización de los servicios es imprescindible el mantenimiento de un
gobierno que establezca y mantenga las normas y políticas para todos los proyectos de TI.
En particular, para la plataforma System z, hay una tendencia a pensar en las aplicaciones
de System z como proveedores de servicios pero, de hecho, las aplicaciones del sistema z
puede ser también consumidoras de servicios. En SOA, cada componente puede ser a la
vez proveedor y el consumidor; y restringir los componentes plataforma System z como
únicamente proveedores hace aumentar la coreografía de servicios innecesariamente. Otro
punto a señalar es que la estratificación o la separación adecuada de las funciones es
bueno y perfectamente aplicable
la arquitectura de
la plataforma System z de
componentes. Al crear nuevas aplicaciones, o renovar las existentes, de los entornos CICS
o IMS, considere un enfoque por capas en los programas con la separación en distintos
módulos de la presentación, la lógica de negocio, la lógica de datos, y del acceso a los
datos.
Por último, un banco de pruebas para las aplicaciones y los procesos es muy importante
para todos los proyectos SOA, Esto no es una cualidad ligada a SOA pero sus
características de heterogeneidad hacen imprescindible disponer de un entorno fiable y
completo para garantizar la calidad del resultado.
Albergando SOA en la plataforma System z.
La Arquitectura Orientada a Servicios (SOA), en su forma más pura, requiere de muy
poca sobrecarga en la infraestructura, la naturaleza de la orientación al servicio,
simplemente dicta una lógica estructuración de código de aplicación que encapsula las
funciones de negocio como servicios. La definición de SOA no hace referencia a algún
tipo de middleware o software de apoyo. Simplemente se refiere a la normalización de
los la interfaz de servicio y a la neutralidad de la plataforma. Sin embargo, en las
grandes implementaciones SOA, no es realmente práctico para aplicar sin necesidad de
herramientas para ayudar a la conectividad y la orquestación de la interacción entre los
servicios. Por otra parte, otras herramientas auxiliares son necesarias en la mayoría de
las implementaciones de SOA, incluyendo desarrollo y herramientas de pruebas,
herramientas de interfaz de usuario como los portales, y la supervisión y aplicaciones
de gestión. En esta sección se describe por qué IBM System z es un ideal plataforma
para el funcionamiento de estas herramientas y productos de middleware que se
encuentran comúnmente utilizados en la aplicación de una SOA.
A medida que las organizaciones adoptan SOA como marco de referencia de
arquitectura para desarrollo de aplicaciones empresariales, la necesidad de desplegar
con rapidez los nuevos servicios se ha convertido en uno de los componentes más
críticos para el negocio de la infraestructura de aplicaciones. Esta implica que los
servicios deben ser tratados como tales, y debe implementarse en una plataforma
robusta, escalable, segura y de alto rendimiento. Junto con los servicios, el middleware
de infraestructura de SOA y las herramientas también deben residir en la plataforma
IBM Corporation
21/02/2011
112 de 131
que acoge el entorno SOA. La plataforma System z, en particular, es el entorno más
adecuado para proporcionar cualidades de servicio que las aplicaciones de una
empresa necesitan.
¿Cuáles son los componentes clave de la infraestructura SOA? La Arquitectura de
Referencia SOA de IBM, que se muestra en la figura anterior, define los elementos y
componentes básicos necesarios para apoyar un entorno SOA.
En el centro de esta arquitectura de referencia está el Enterprise Service Bus (ESB).
Alrededor del ESB están los servicios esenciales necesarios para soportar la ejecución
de un ambiente SOA: servicios de interacción, servicios de procesos, servicios de
información, los servicios de asociados, servicios de aplicación empresarial, y servicios
de acceso. En los siguientes párrafos nos referiremos brevemente a cada uno de estos
elementos. Junto con los servicios básicos, las casillas que los rodean escriben las
demás funciones que serán necesarias para apoyar los servicios antes, durante y
después de su despliegue. Tanto el Websphere Message Broker como el Websphere
ESB son productos que pueden utilizarse para realizar estas funciones con la calidad
necesaria para la plataforma System z.
6.1.4.1
Servicios de Infraestructura
En la base de la Arquitectura de Referencia SOA está la plataforma para su
implementación. Esto incluye el despliegue del hardware y software para los servicios
de negocio y los servicios de infraestructura. Un entorno de producción por lo general
requiere el más alta grado de calidad de servicio (QoS), y el componente de los
servicios de infraestructura proporciona la calidad de servicio. Los servicios de esta
capa incluyen las funciones del sistema operativo, las de seguridad, y las de hardware.
Esta exigencia de un alto nivel de servicio es en la plataforma System z donde juega un
importante papel. Teniendo en cuenta las misiones de naturaleza crítica, las funciones
de la plataforma añaden el más alto grado de escalabilidad, confiabilidad, y seguridad;
tanto el Security Server, para la implementación de la seguridad, como los Servicios de
Recuperación de Recursos (RRS), para el soporte nativo del “two phase commit” y
garantizar la integridad de las transacciones con acceso a múltiples sistemas, son dos
claros ejemplos de los valores que aporta la plataforma System z a la arquitectura SOA.
6.1.4.2
Servicios de Desarrollo
Las fases Model y Assemble del ciclo de vida SOA hacen un amplio uso de los servicios
de desarrollo de la arquitectura. Los servicios de desarrollo incluyen las herramientas
que se utilizan para el modelado y el montaje de los servicios de negocio. El modelado
consiste en el modelado de los procesos de negocio y el modelado de los servicios
reales de negocio y de la lógica de negocio dentro de ellas. Las herramientas pueden
ser las herramientas del más alto nivel adecuado para los analistas de negocio y,
herramientas de menor nivel, como los utilizados para el desarrollo orientado a objetos.
IBM Corporation
21/02/2011
113 de 131
La salida de estas herramientas consta de artefactos tales como los modelos UML, el
código fuente de la aplicación real en una variedad de lenguajes como Java o COBOL,
y lenguajes de marcado como XML y el lenguaje de ejecución de procesos
empresariales (BPEL).
Desde la perspectiva de System z, la mayoría del código de desarrollo y las
herramientas de modelado no se ejecutan en el Mainframe. Sin embargo, si el cliente
desea construir nuevos servicios o la reutilización de servicios ya existentes en el
Mainframe, herramientas como el WebSphere Integration Developer o el WebSphere
Developer para zSeries se utilizan para construir e integrar los servicios que se
desplegarán en el Mainframe.
6.1.4.3
Servicios de Gestión TI
Los componentes de la infraestructura SOA consisten principalmente en middleware.
Al igual que las arquitecturas de aplicaciones tradicionales, una implementación SOA
requiere de los niveles adecuados de supervisión y gestión del middleware y
aplicaciones para garantizar un nivel adecuado de rendimiento del sistema y su
seguridad.
Esto es particularmente importante en un sistema basado en SOA ya que las
aplicaciones compuestas SOA puede abarcar varias plataformas de computación y
redes, y podrá exigir garantías y contextos transaccionales que se llevarán a partir de
un servidor o sistema operativo a otro. La depuración y corrección de errores, los
problemas de rendimiento en este entorno requiere una buena supervisión y
herramientas de gestión.
Muchas herramientas de la cartera de Tivoli proporcionan la funcionalidad para la
gestión de servicios de TI. Algunos ejemplos: para supervisar el rendimiento de extremo
a extremo, IBM Tivoli Composite Application Manager for SOA y el Tivoli Omegamon
proporcionan las herramientas de seguimiento necesarias para controlar los
componentes en una aplicación de varios niveles que abarca distribuidos y sistemas
Mainframe.
6.1.4.4
Servicios de innovación y optimización de los Negocios
Si bien la infraestructura de TI se controla y gestiona a través de los servicios de TI
componentes de gestión, ¿qué pasa con los servicios de negocio? Una organización
pueda garantizar un nivel adecuado de rendimiento del sistema y aplicación, pero ¿qué
pasa con el rendimiento del negocio? La innovación empresarial y servicios de
optimización componente proporcionan la funcionalidad necesaria para una efectiva
supervisión y registrar lo que se pasando en la empresa desde una perspectiva
puramente empresarial. ¿Cuántos aparatos se vendieron en la última hora / día / mes /
año? ¿Cuánto tarda en arrancarse el proceso de atención al cliente? ¿Cuántos clientes
hicieron una petición de servicio ayer? Este componente proporciona las herramientas
necesarias para controlar este tipo de funciones de negocios, el informe de los
resultados y pasar los resultados a las herramientas de modelado (utilizado en el
componente de desarrollo de los servicios) de manera que los procesos se pueden
modelar con más precisión, se puedan realizar simulaciones, y se pueden hacer
modificaciones a los procesos empresariales para mejorar aún más la eficacia de la
empresa.
El WebSphere Business Monitor ofrece un monitor que vigila los servicios de negocio y
acumula los informes y las estadísticas acerca de cómo las funciones de negocio están
realizando. De nuevo, esto no es una pregunta como "¿Cómo de rápida es la ejecución
de esta transacción?". En su lugar, se pregunta y responde "¿Cuántos de estas
funciones de la empresa estamos realizando y con qué eficiencia las estamos
haciendo?”.
IBM Corporation
21/02/2011
114 de 131
6.1.4.5
Servicios de Interacción
El componente de interacción de servicios proporciona la interfaz de usuario de la
solicitud SOA. Un principio clave de SOA es la abstracción de las capas de aplicación.
En este caso, la interfaz de la aplicación de usuario (UI) está expuesta en una capa
separada de la lógica de negocio. Los servicios de interacción se piensan comúnmente
como la capa de portal, desde la interfaz de usuario para muchas aplicaciones SOA se
proporciona un portal, aunque esto componente no es obligatorio.
El portal no sólo proporciona una abstracción de la interfaz de usuario,
sino que también proporciona un conjunto estándar de servicios para el usuario final y
una experiencia de usuario personalizada. Con las nuevas normas tales como Web
Services para Remoto Portlets (WSRP), aplicaciones de portal (portlets) puede ser más
fácil vinculadas a los servicios para facilitar la integración entre la interfaz de usuario y
la lógica de los servicios de negocio.
WebSphere Portal Server es el componente principal de proporcionar una interacción
los servicios y está disponible en la plataforma System z (así como en las plataformas
distribuidas).
Como se mencionó anteriormente, en un diseño de SOA, la proximidad a los servicios,
transacciones y datos es un principio básico del diseño arquitectónico. La colocación de
un portal en la plataforma, cerca de los servicios que se invoca, reduce los gastos
generales de comunicación y los puntos de fallo.
6.1.4.6
Servicios de Procesos
Un atributo clave de una aplicación SOA es que a menudo es una “aplicación
compuesta, es decir una que se construye a partir de varios servicios discretos, todos
ellos conectados a través de algún tipo de motor de orquestación. El proceso de los
servicios componentes proporciona la orquestación de flujo de trabajo y servicios que
se requieren para fusionar múltiples servicios en una sola aplicación. Esta aplicación
puede ser una sola transacción, o puede ser una serie de transacciones que se unieron
en un proceso de negocio.
El WebSphere Process Server (WPS), y en menor medida, de WebSphere
Message Broker (WMB), actúan como servidores de la coreografía de procesos. WPS
provee orquestación de servicios múltiples, impulsado por un "guión" se expresa en
BPEL. WPS es el ejecutor de BPEL. WMB ejecuta los "flujos de mensajes" provocados
por los mensajes entrantes, y puede invocar funciones y servicios múltiples. WMB se
utilizaría para los servicios que se agrupan en una
sola transacción.
El WPS puede albergarse en la plataforma System z. La colocación de este
componentes en System z satisface el principio de arquitectura de la proximidad a los
datos y transacciones.
6.1.4.7
Servicios de Información
Los datos están en todas partes. En las últimas décadas, las empresas han recogido
grandes cantidades de datos en diferentes repositorios en todo el negocio. Los servicios
de información proporcionan acceso basado en SOA para los repositorios de datos a
través de técnicas tales como el acceso a los procedimientos almacenados como
servicios Web, proporcionando interfaces estándar para los depósitos de datos no
relacionales, y acceder a otras mecanismos que devuelven información como un
IBM Corporation
21/02/2011
115 de 131
servicio (IAAS). Puesto que los datos o información en sí misma no son "ejecutables",
se necesita una infraestructura para exponer los datos a las aplicaciones que utilicen
estándares SOA como SOAP.
Muchos de los datos críticos del patrimonio de la empresa residen en el Mainframe. IBM
proporciona una serie de z herramientas basadas en la plataforma System z para
exponer los datos como IAAS. El propio DB2 para z / OS propio motor, y el WebSphere
Information Integrator Classic Federation para z/OS (IICF). IICF proporciona una
interfaz SQL para una serie de formatos de datos “legacy”, como VSAM, IMS DB, y de
otros fabricantes de bases de datos incluyendo CA-Datacom, CA IDMS, y Adabas de
Software AG.
6.1.4.8
Servicios de integración
El componente de servicios de integración de socios es la interfaz para socios de
negocios externos. La exposición de los servicios empresariales con el mundo exterior y
la invocación de servicios externos plantean desafíos a la integridad y a la seguridad del
entorno SOA. Los servicios deben ser expuestos de una manera que mantenga la
seguridad y la escalabilidad del servicio, ya que esto hace que los patrones de uso del
servicio sean mucho menos predecibles y controlables que si se está accediendo
exclusivamente desde la propia organización. Históricamente, gran parte de la
interacción con los socios externos se ha hecho a través de mecanismos tales como
EDI.
Los servicios de asociados se proporcionan en el Mainframe a través de canales
tradicionales, como WebSphere Data Interchange, para la traducción EDI. El socio de
WebSphere Partner Gateway de la cara al mundo exterior.
6.1.4.9
Servicios de Aplicaciones de Negocio
El recién desarrollado servicios de residir en el negocio de servicios de aplicaciones
componentes. Estos nuevos servicios son generalmente implementarse en servidores,
como IBM WebSphere Application Server, que es un administrador de transacciones
para Java 2 Enterprise Edition (J2EE). El servidor de aplicaciones WebSphere puede
utilizarse para aplicaciones con todas las funciones (presentación, lógica de negocio, y
los datos lógica), o puede alojar los servicios de negocio que tienen las otras funciones
de abstracción en otras partes de la arquitectura de referencia (ver Servicios Interacción
y Servicios de Información).
WebSphere Application Server está disponible en la plataforma System z tanto en z /
OS y en zLinux. En zLinux la versión es idéntica a la versión de WAS para plataformas
distribuidas. Sin embargo, el WebSphere Application Server para z / OS es ligeramente
diferente ya que explota el subyacente z / OS y aprovecha las funciones específicas del
sistema sin sacrificar la portabilidad de aplicaciones.
6.1.4.10 Servicos de Acceso
De particular interés para los clientes de Mainframe es el componente de los servicios
de acceso, la vinculación con las aplicaciones existentes, tanto dentro como fuera del
Mainframe. Este componente proporciona la conectividad a las aplicaciones IMS, CICS,
SAP, PeopleSoft, etc., utilizando diversos conectores y adaptadores con diversas
tecnologías.
IBM Corporation
21/02/2011
116 de 131
6.1.4.11 Enterprise Service Bus
Aunque el bus de servicios empresariales (ESB) es el último tema que se presenta, es
en realidad el punto crítico de la arquitectura de referencia. De la figura anterior se
desprende que el ESB es, literalmente, el centro de la arquitectura de referencia de
SOA, y que es importante para cualquier implementación de SOA. El ESB proporciona
la capa de abstracción entre el solicitante del servicio y el proveedor del servicio. En las
antiguas aplicaciones no-SOA, los vínculos entre las aplicaciones son con frecuencia no
modificables y puedes ser difíciles de gestionar y mantener. Para cambiar las relaciones
entre los programas, puede ser necesario cambiar las aplicaciones según evolucione el
negocio o la tecnología.
La definición de IBM de un bus de servicios empresariales es el de una construcción
arquitectónica y no la de un producto específico. La ESB debe apoyar cuatro funciones
principales:
Enrutamiento de mensajes entre los servicios, eliminando la relación directa entre los
interlocutores.
La conversión de protocolos de transporte entre el solicitante y el servicio, por ejemplo,
SOAP a MQ, FTP para excitato, y así sucesivamente.
La transformación de formatos de mensaje, por ejemplo, la transformación de XML a
binario.
Manejo de eventos de diferentes fuentes. Los eventos son recibidos del ESB con
criterios de valoración y se correlacionan para desencadenar nuevos eventos basados
en las decisiones en el ESB.
Cualquier producto o los productos que realizan las funciones requeridas se pueden
clasificar como una aplicación de ESB.
Los productos WebSphere Enterprise Service Bus y el WebSphere Message Broker son
la base del ESB en la solución SOA de IBM. Proporcionan las cuatro primarias
funciones del ESB, y cuando se combinan con el WebSphere Process Server para la
orquestación, los clientes de IBM tienen una infraestructura muy sólida para SOA.
La plataforma System z es el lugar ideal para colocar un ESB. Tanto el WebSphere
Message Broker como el WebSphere ESB están disponibles en la plataforma System z
con una escalabilidad y rendimiento imbatibles. La alta confiabilidad, disponibilidad y
seguridad de la plataforma System z son atributos clave para un ESB. El ESB es un
componente crítico de la arquitectura, realizando el encaminamiento de las llamadas
de servicio para todas las transacciones SOA. Tiene sentido de poner la parte más
crítica de la arquitectura en la plataforma que posee la más alta calidad en las
características del servicio, junto con la proximidad a aplicaciones y datos.
6.2 Proceso en nube (Cloud computing).
En los últimos años se ha hablado mucho de ‘cloud computing’ pero ¿qué es Pproceso
en nube?.
IBM Corporation
21/02/2011
117 de 131
En primer lugar debemos decir que existen dos puntos de vista a la hora de definir este
‘nuevo’6 concepto:
Desde el punto de vista del usuario, o del modelo de negocio, podemos decir que el
proceso en nube es un nueva forma de proporcionar servicios de IT, en la cual las
aplicaciones, los datos y los recursos se aprovisionan rápidamente y se proporcionan
como una oferta estándar a los usuarios a través de la web con un modelo de precios
flexible.
Desde el punto de vista de la administración de infraestructura tecnológica y de
metodología de entrega de servicios, el proceso en nube es una forma de administrar
un gran número de recursos altamente virtualizados tales que, desde el punto de vista
de la administración, éstos parecen un único y gran recurso. Entonces se pueden
utilizar estos recursos para ofrecer unos servicios estandarizados con una escalabilidad
elástica.
Con el concepto de proceso en nube aparecen dos formas de ofrecer estos servicios:
‘nube privada’ y ‘nube pública’. La diferencia entre ellas es, por supuesto, quién ofrece
dichos servicios y para quién los ofrecen. La ‘nube pública’ se caracteriza por estar
abierta a cualquiera que pueda pagar sus servicios, tal cual los ofrezca el proveedor. Su
caracteristica principal es que tiene un control bajo y un alto valor. Son las nubes del
tipo de redes sociales ofrecidas por GOOGLE. La nube privada por el contrario es
aquélla que poseen las compañías, y en las cuales los usuarios son aquéllos que
designan dichas compañías. Su característica principal es que poseen un buen control
y un valor bajo. Podemos considerar como un tipo de esta nube, las herramientas de
colaboración que proporcionan las empresas a sus empleados.
Por supuesto, entre una y otra hay una especie de continuo, conocido como hybrido.
6
‘Nuevo’ en la forma de referirnos a ello. En realidad más que un nuevo concepto es una
evolución, como veremos más adelante
IBM Corporation
21/02/2011
118 de 131
Podemos considerar los siguientes pros a la hora de decidirnos por una nube privada:
más control, menos latencia, más seguridad, un entorno de aprendizaje, un cambio de
paradigma de precio/coste a precio/valor.
Una vez vistos los conceptos ya entendemos por qué más que una revolución es una
evolución:
Esta escala nos muestra el camino que se ha seguido para llegar al cloud computing
desde el mundo x86, pero, a mi me suena a una vieja y modernizada vuelta al mundo
del ‘centro de procesos’. En la Universidad a mi me proporcionaron una ‘cuenta’ que era
una máquina VM en la que podía correr mis programas FORTRAN para solucionar los
problemas que me proponían….
Desde el punto de vista de la informática de gestión tenemos lo siguiente:
Dónde podemos ver que la puesta en marcha de estas nubes privadas requieren un
alto grado de virtualización y estandarización, además de los servicios de
automatización pertinentes, para poder llegar a una nube efectiva.
¿Cómo afecta esto al System z?
Podemos decir que la propia arquitectura del mainframe ha evolucionado por sí misma
para llegar a este punto sin traumas:
IBM Corporation
21/02/2011
119 de 131
Ya hemos hablado del alto grado de virtualización que el System z proporciona. De su
seguridad inigualable, De los miles de usuarios que el zVM puede soportar
proporcionando a cada uno una visión de máquina propia. Todo esto son las bases del
cloud computing, Si le unimos el rápido aprovisionamiento y la gran automatización que
se puede conseguir, tenemos construida la nube sin más.
Un dato más: el System z consigue una utilización del 90% sin merma de su
rendimiento, dato que queda muy lejos del 38% de utilización que consigue el tipo de
nube basada en x86 (GOOGLE). Esto se engarza con el mayor consumo de energía de
estas nubes y la mayor creación de ‘basura tecnológica’ que se genera, aparte de
algunos otros ítems, como podemos ver en las siguientes gráficas:
IBM Corporation
21/02/2011
120 de 131
Con todo esto, IBM tiene actualmente varias ofertas de proceso en nube para el System
z que, sin duda, irán creciendo a lo largo del tiempo.
IBM Corporation
21/02/2011
121 de 131
La evolución del IBM System z: zEnterprise
Casi todas las organizaciones se enfrentan a obstáculos informáticos en su camino al éxito
empresarial. Los silos de tecnologías obsoletas no son compatibles con procesos que
deben extenderse a toda la empresa. Las soluciones puntuales no proporcionan la calidad
de servicio necesaria para sus aplicaciones más importantes con un ámbito empresarial.
Puede que haya sustituido o refinanciado sistemas existentes en un interno de modernizar
su infraestructura. Sin embargo, se habrá dado cuenta de que el coste de estas migraciones
suele ser superior al esperado y de que supone un riesgo importante.
Los costes de sustitución de cada aplicación antigua estimados en entre 20 y 80 euros
por línea suponen cientos de miles de millones de euros.
La refinanciación implica grandes costes y riesgos: una lógica empresarial deteriorada y
retrasos prolongados suelen acompañar a un desarrollo de primer nivel.
La modernización de activos existentes puede llevar a una mejora cinco veces
superior respecto a un costoso enfoque de "quita y pon".
El aprovechamiento de inversiones existentes, en vez de sustituir o refinanciarlas, es un
enfoque demostrado que permite obtener ventajas competitivas. Las arquitecturas orientada
a los servicios (SOA) y las nuevas tecnologías pueden ayudar a cualquier Organización a
modernizar, ampliar y reutilizar activos existentes a la vez que ahorran tiempo y dinero, y
reducen riesgos. Tras la modernización, estos sistemas de TI ofrecen una mayor agilidad,
flexibilidad y solidez, además de poder aumentar la productividad, lo que le permite
responder con rapidez a las dinámicas de mercado y a las cambiantes necesidades
comerciales.
La inversión que IBM ha realizado en la plataforma System z, que integra hardware y
software con interfaces modernas y abiertas, permite a las organizaciones reinventar sus
operaciones empresariales con el fin de obtener valor a corto plazo, e implantar nuevas
prestaciones comerciales que aprovechan las inversiones existentes. Los mainframes de
IBM System z proporcionan la plataforma ideal para cargas de trabajo empresariales
estratégicas, ofrecen una integración sin igual en toda la plataforma e incorporan
tecnologías que aceleran la implantación de nuevas prestaciones.
En definitiva, el camino a la modernización puede cambiar la forma en la que una
Organización desarrolle, gestione y proporcione soluciones de TI; también puede mejorar
todas sus operaciones desde sistemas a procesos y personas.
Modernización empresarial en zEnterprise
IBM zEnterprise System (zEnterprise) cubre los desafíos únicos de la informática
empresarial. Gracias a este sistema, una Organización puede implantar una plataforma
de hardware completamente integrada que abarca su empresa, mainframe integrados,
tecnologías POWER7 y x86. Podrá consolidar con efectividad islas informáticas, reducir
la complejidad, mejorar la seguridad y acercar aplicaciones a los datos que necesitan.
Con el zEnterprise puede ampliar el control inspirado en mainframe y las calidades de
servicio para optimizadores de carga de trabajo para propósitos especiales e IBM
Blades (selección de aplicaciones IBM POWER7 y System x Blades para AIX y Linux
IBM Corporation
21/02/2011
122 de 131
sobre System x). IBM zEnterprise Unified Resource Manager ofrece entornos
heterogéneos conjuntamente en un único sistema, lo que proporciona a la Organización
una gestión centralizada e integrada de todos los aspectos operativos críticos, incluidos
supervisión y gestión de la energía, gestión de políticas orientadas al objetivo, aumento
de la seguridad, redes virtuales y gestión de datos, consolidados en una única interfaz
que se puede unir a los requisitos comerciales.
IBM zEnterprise
The integration of System z and distributed technologies into a
revolutionary combination
IBM zEnterprise
Unified Resource Manager
IBM zCPC
Unifies resources, extending System z qualities of
service across the infrastructure
Install, Monitor, Manage, Optimize, Diagnose &
Service
Server Blades
The industry’s fastest
and most scalable
enterprise server
Ideally suited for large
scale data and
transaction serving
and mission critical
enterprise
applications
Runs app unchanged and
supports what you know.
Logical device integration
between System z and
distributed resources
Optimizers
HMC
1
IBM zEnterprise
BladeCenter Extension
Workload specific
accelerators to deliver
significant performance
and/or lower cost per
transaction
All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represents goals and objectives only.
© 2010 IBM Corporation
zEnterprise cuenta con dos componentes principales: IBM zEnterprise 196 (z196),
tradicionalmente conocido como Central Electronic Complex (CEC) y IBM zEnterprise
BladeCenter Extension (zBX). La infraestructura zBX funciona con z196 para ser
compatible con el entorno multiplataforma zEnterprise. zBX tiene instalados
optimizadores de carga de trabajo para propósitos especiales como el nuevo IBM Smart
Analytics Optimiser para DB2 para z/OS V1.1, y IBM Blades para propósitos generales
desarrollados por IBM POWER7. (Existe una declaración de dirección para añadir un
blade basado en System x en un futuro próximo.) Puede ejecutar una aplicación que
abarque z/OS, Linux® en System z, AIX en POWER, o Linux en System x bajo un
paraguas de gestión único. System z ofrece a los departamentos de TI la protección de
su inversión, reducción de la complejidad, flexibilidad mejorada y un menor coste de la
propiedad. Unified Resource Manager puede ayudar a proporcionar una gestión y
virtualización integrales, y la capacidad de optimizar la implantación de recursos de
acuerdo con los requisitos de carga de trabajo individuales.
IBM Corporation
21/02/2011
123 de 131
IBM System z: System Design Comparison
System I/O Bandwidth
288 GB/Sec*
Balanced System
CPU, nWay, Memory,
I/O Bandwidth*
172.8 GB/sec*
96 GB/sec
Memory
3 TB**
24 GB/sec
1.5 TB**
512 GB
256
GB
300
64
GB
450
600
920
ITR for
1-way
~1200
16-way
32-way
zEnterprise GA1
54-way
64-way
z10 EC
z9 EC
zSeries 990
* Servers exploit a subset of its designed I/O capability
** Up to 1 TB per LPAR
80-way
Processors
zEnterpriseTLLB_21
zSeries 900
© 2010 IBM Corporation
Transformar sus activos de TI para proteger sus inversiones
Muchos lenguajes y aplicaciones antiguos del mainframe están estancados y carecen
de funcionalidad, interfaces y estándares para permitir la integración con nuevas cargas
de trabajo o un cambio rápido de la lógica empresarial para resolver los nuevos
requisitos comerciales. Estas aplicaciones importantes para la empresa a menudo
representan grandes inversiones durante años, y las organizaciones que desean
implantar nuevos clientes o paquetes de aplicaciones no quieren arriesgarse a
refinanciar aplicaciones de "quita y pon".
Desde los antiguos lenguajes 4GL a COBOL y Java™, zEnterprise es compatible con
los conjuntos más completos del sector en lenguajes y entornos operativos, lo que
puede ayudar a cualquier Organización a obtener el máximo valor de sus inversiones
existentes y a respaldar una amplia diversidad de iniciativas de arquitectura y
modernización. Nuestras inversiones en herramientas Rational Developer y
ampliaciones de migración pueden ayudarle a reducir los costes operativos asociados a
tecnologías obsoletas y proporcionar silos de desarrollo bajo una solución común de
gestión del ciclo de vida relativa a aplicaciones y programación basada en equipos.
Modernice su empresa para maximizar la agilidad
La plataforma System z incluye tecnologías modernas que pueden permitir a una
Organización a utilizar los elementos existentes de su infraestructura de aplicaciones de
IBM Corporation
21/02/2011
124 de 131
manera innovadora. La integración de procesamiento rentable y de alto rendimiento de
Java™ y XML proporciona un entorno sólido de arquitectura orientada a servicios
(SOA) que puede resolver los requisitos empresariales del mañana sin tener que
rehacer la inversión de su organización en aplicaciones comerciales estratégicas.
Aprovechar una solución Smart SOA para habilitar aplicaciones antiguas para el
servicio y la web con el fin de la reutilización puede eliminar la complejidad y mejorar la
calidad. Cualquier Organización podrá mejorar drásticamente el rendimiento mediante
la promoción de la reutilización de activos clave que ya estén en funcionamiento en su
entorno. Y, por ello, salir al mercado con mayor rapidez con ciclos de desarrollo más
reducidos.
La integración de zEnterprise de activos heterogéneos bajo un conjunto común de
recursos gestionados y conectados con una red privada de datos a alta velocidad
ofrece a la Organización niveles mejorados de integración, gestión de sistemas,
rendimiento, calidad y seguridad para la implantación de sus aplicaciones basadas en
arquitecturas orientadas a servicios. Sus modernas cargas de trabajo de WebSphere y
Java pueden obtener un rendimiento mejorado de hasta el 60 por ciento en zEnterprise.
IBM Corporation
21/02/2011
125 de 131
Consolidación de servidores
En este anexo vamos a incluir una serie de consideraciones sobre la consolidación de
servidores y las ventajas que la plataforma System z aporta en sus diversas
aproximaciones.
Introducción
La consolidación es mucho más que la simple sustitución de una gran cantidad de
pequeños servidores por un menor número de servidores más grandes, más potentes.
La consolidación es encontrar maneras de alinear y administrar la infraestructura de TI
existente para apoyar mejor el modelo de negocio, la mismo tiempo que se establece
una base flexible diseñada para manejar las posibles necesidades futuras.
El objetivo es optimizar y simplificar la infraestructura de TI de principio a fin, no sólo los
servidores, sino también el almacenamiento, los datos, las aplicaciones, las recursos de
las redes, y las herramientas del sistema de gestión que ayudan a ver toda la
infraestructura como un único elemento.
Además de ofrecer el potencial de ahorro de costes y mejoras en la eficiencia,
disponibilidad y la productividad, la consolidación puede proporcionar una base estable
para el
despliegue rápido de nuevas iniciativas según las necesidades del negocio
evolucionen.
Típicamente, una carga de trabajo UNIX, Linux o Microsoft ® Windows ®, está
físicamente dividida en diferentes servidores físicos. Los servidores distribuidos
normalmente cuentan con grandes espacios vacios para manejar picos de carga de
trabajo. Estos servidores, por lo general, tiene una ocupación media muy baja
(Windows 5% - 10%, UNIX 25% -30%).
Estas cargas de trabajo son claros candidatos para una consolidación y aprovechar sus
ventajas. Los principales beneficios de la consolidación son los siguientes:
•
Disminuir el costo total de propiedad (TCO)
La consolidación puede ayudar a reducir la complejidad, establecer un mejor
sistema de políticas y prácticas de gestión, optimizar la utilización de los
recursos y controlar la espiral de consumo de hardware y los costes de las
licencias de software.
•
Mejora de los niveles de servicio de aplicaciones
La consolidación puede ayudar a habilitar las aplicaciones que impulsan la
integración de la empresa facilitando a los usuarios un mejor acceso a los
datos, mayores niveles de disponibilidad, y mejores tiempos de respuesta.
•
Mayor seguridad y resiliencia operativa
La consolidación puede ayudar a controlar la seguridad de la información
clave. Aprovechando las capacidades, líderes en la industria de TI, del System
z se pueden conseguir entornos seguros, ágiles, próximos al 24x7, altamente
resistentes a las interrupciones no planificadas, adaptarse a los cambios y con
rápida recuperación. .
•
La información como herramienta estratégica de negocios
El modelo de computación distribuida a menudo crea islas de las aplicaciones
y datos. La consolidación de los recursos de TI puede ayudar a asegurar que
los datos críticos de negocio, y los procesos son accesibles y compartidos a
través de la empresa.
IBM Corporation
21/02/2011
126 de 131
Tipos de Consolidación.
En el siguiente gráfico se representan los diferentes tipos de consolidación y las
ventajas inherentes junto con los esfuerzos y riesgos asociados.
Se puede realizar una Consolidación de CPD (Site Consolidation) que
Consolidación en System z
Los puntos fuertes de la plataforma System z (su capacidad para ejecutar múltiples
tipos de carga de trabajo con una fiabilidad excepcional, rendimiento, seguridad y
administración) han sido imitadas pero nunca igualada por las plataformas de servidor.
La visión básica de una consolidación en Systemz es la realización de un Centro de
Datos en una caja, no con una granja de servidores.
Las siguientes características de la plataforma System z la hacen ideal para
consolidaciones:
•
La Arquitectura z está diseñado para manejar cargas de trabajo heterogéneas.
El Workload Manager (WLM) y el Intelligent Resource Director (IRD) realizan la
gestión de cargas de trabajo mixtas y de los recursos de computación para
permitir a las aplicaciones que comparten todos los elementos del sistema.
IBM Corporation
21/02/2011
127 de 131
•
La plataforma System z incluye tecnologías avanzadas de virtualización.
•
La plataforma System z tiene una fuerte historia como servidor de datos. Su
arquitectura está diseñado para el acceso masivo a los datos, ya sea a través
de Internet, a dispositivos de almacenamiento, o a sitios remotos de respaldo. El
procesador especializado zIIP hace la integración de datos más atractiva.
•
Construido sobre el WebSphere Application Server para z / OS, el System z
incluye una gran pila de productos de middleware orientados a soportar las
nuevas cargas de trabajo para la empresa on demand. El procesador
especializado zAAP hace más rentable la ejecución de trabajos Java en el
systemz.
•
El entorno de System z ha sido diseñado para ofrecer integridad y soluciones
de seguridad completas para ayudar a satisfacer las demandas actuales de
explotación en materia de seguridad.
•
La plataforma System z proporciona QoS inigualables. La consolidación en el
System z permite que las aplicaciones aprovechen su excepcional fiabilidad,
alta disponibilidad, escalabilidad, capacidad de servicio y capacidad de
recuperación.
•
Sofisticados sistemas de control y de gestión han estado disponibles en el
System z durante años. (Consulte la sección "Gestión de sistemas" en la página
107.)
El system z proporciona diferentes sistemas operativos e, incluso, diversos
procesadores que permite hoy albergar cualquier tipo de carga de trabajo. Un estudio
de arquitectura permitirá definir la colocación adecuada de cada una de dichas cargas.
IBM Corporation
21/02/2011
128 de 131
IBM Corporation
21/02/2011
129 de 131
7 Bibliografía
Sin pretender ser exhaustivos,incluimos una relación de documentos sobre el System z
que pueden ser de interés para profundizar en el conocimiento de las características
que hemos descrito someramente en los capítulos anteriores.
•
•
•
•
•
•
•
•
•
•
•
GDPS Family - An Introduction to Concepts and Capabilities, SG24-6374
IBM System z9 and eServer zSeries Connectivity Handbook, SG24-5444
IBM zSeries 990 Technical Guide, SG24-6947
IBM System z9 Business Class Technical Introduction, SG24-7241
IBM System z9 Enterprise Class Technical Guide, SG24-7124
IBM System z9 109 Technical Guide, SG24-7124
IBM System z9 and eServer zSeries Connectivity Handbook, SG24-5444
OS/390 Workload Manager Implementation and Exploitation, SG24-5326
ABCs of z/OS System Programming Volume 3 - Introduction to DFSMS, data set
basics, storage management hardware and software, VSAM, System-managed
storage, catalogs, and DFSMStvs, SG24-6983
ABCs of z/OS System Programming Volume 5 - Base and Parallel Sysplex, GRS,
RRS; System Logger, z/OS system operations; ARM, GDPS, zSeries availability,
SG24-6985
ABCs of z/OS System Programming Volume 10 - Introduction to z/Architecture,
zSeries processor design, zSeries connectivity, LPAR concepts, HCD, and DS8000,
SG24-6990
ABCs of z/OS System Programming Volume 11 - Capacity planning, performance
management, WLM, RMF, SMF, SG24-6327
Introduction to the New Mainframe: z/OS Basics, SG24-6366
Introduction to the New Mainframe: Security, SG24-6776
•
Introduction to the New Mainframe: Large-Scale Commercial Computing, SG247175
IBM System z Strengths and Values, SG24-7333
•
The IBM TotalStorage DS8000 Series: Concepts and Architecture, SG24-6452
DFSMShsm Fast Replication Technical Guide, SG24-7069
The IBM TotalStorage® DS6000™ Series: Copy Services with IBM Eserver zSeries,
SG24-6782
A Practical Guide to the IBM Autonomic Computing Toolkit, SG24-6635
•
Problem Determination Using Self-Managing Autonomic Technology, SG246665
S/390 Time Management and IBM 9037 Sysplex Timer, SG24-2070
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
z/OS V1R1.0 Parallel Sysplex Application Migration, SA22-7662
z/OS V1R1.0 Parallel Sysplex Overview: An Introduction to Data Sharing and Parallelism, A22-7661
z/OS V1R7.0 MVS Setting Up a Sysplex, SA22-7625
Large Systems Performance Reference, SC28-1187
Security on z/OS: Comprehensive, current, and flexible, Guski et al. IBM Systems
Journal, Vol.40, No.3, 2001, pp.696-720, G321-0142
http://www.research.ibm.com/journal/sj/403/guski.html
IBM eServer zSeries Security Leadership for the On Demand World, GM13-0644
http://www.ibm.com/servers/eserver/zseries/library/whitepapers/pdf/Security_TL.pdf
IBM eServer z990, IBM Journal Research and Development, Vol. 48, No. 3/4, 2004
Cluster architectures and S/390 Parallel Sysplex scalability by G. M. King, D. M.
Dias, and P. S. Yu, IBM System Journal Volume 36, Number 2, 1997
z/OS: MVS System Management Facilities (SMF), SA22-7630
IBM SMP/E for z/OS User's Guide, SA22-7773
Y con Internet a través de los siguientes enlaces:
•
•
IBM terminology: http://www.ibm.com/ibm/terminology
IBM Redbooks: http://www.redbooks.ibm.com/
IBM Corporation
21/02/2011
130 de 131
•
•
•
•
•
General information about IBM System z: http://www.ibm.com/systems/z
IBM Geographically Dispersed Parallel Sysplex:
http://www.ibm.com/servers/eserver/zseries/gdps
IBM Storage Solutions: Overview - IBM System Storage:
http://www.ibm.com/servers/storage/solutions/
•
Parallel Sysplex home page: http://www.ibm.com/servers/eserver/zseries/pso/
z/OS basic skills information center:
http://publib.boulder.ibm.com/infocenter/zoslnctr/v1r7/index.jsp
General mainframe information: http://www.mainframe.typepad.com/
Scaling - up or out: http://www.redbooks.ibm.com/abstracts/redp0436.html
z/OS Workload Manager - how it works and how to use it:
•
http://www.ibm.com/servers/eserver/zseries/zos/wlm/pdf/zWLM.pdf
The Autonomic Computing home page: http://www.ibm.com/autonomic
•
•
IBM Corporation
21/02/2011
131 de 131