Diseño e implementación de arquitectura hardware (HA) para sistemas de planificación de recursos empresariales (ERP)

Proyecto Final de Carrera DISEÑO E IMPLANTACIÓN DE ARQUITECTURA HARDWARE DE ALTA DISPONIBILIDAD (HA) PARA SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES (ERP) Esteban Atienza Quesada Dirección del proyecto: Juan Luis Posadas Yagüe DISCA – Departamento de Informática de Sistemas y Computación Facultad de Informática de Valencia Universidad Politécnica de Valencia Valencia, junio de 2010 Índice de contenidos Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 3 CAPÍTULO 1 - INTRODUCCIÓN AL PROYECTO.......................................................... 6 1.1. Motivación.............................................................................................................6 1.2. Objetivo.................................................................................................................6 1.3. Organización.......................................................................................................... 6 CAPÍTULO 2 - EL CONCEPTO DE ALTA DISPONIBILIDAD (HA) ............................. 8 2.1. Introducción................................................................................................................ 8 2.2. Alta Disponibilidad en las organizaciones .................................................................8 2.3. Determinación de las necesidades de disponibilidad del cliente................................ 9 2.4. Niveles de disponibilidad .........................................................................................10 2.5. Causas posibles del tiempo de inactividad o interrupción........................................11 2.5.1. Interrupciones no planificadas...........................................................................11 2.5.2. Interrupciones planificadas................................................................................12 2.6. ¿Cómo se puede implementar alta disponibilidad?.................................................12 2.6.1. Protección contra anomalías en el disco............................................................12 2.6.2. Planificación para una pérdida de alimentación................................................ 13 2.6.3. Uso de métodos eficaces de gestión de sistemas............................................... 14 2.6.4. Preparación del espacio para el servidor ........................................................... 15 2.6.5. Backups .............................................................................................................15 2.6.6. Software de replicación remota.........................................................................15 2.6.7. Caminos de red redundantes o Multipath / Path Failover ................................. 16 2.6.8. Clústeres y programas altamente disponibles....................................................17 CAPÍTULO 3 - SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES (ERP)................................................................................................................................... 18 3.1. Introducción.............................................................................................................. 18 3.2. La necesidad de un software de gestión integral (ERP)...........................................18 3.2.1. La evolución de los sistemas informáticos de gestión.......................................18 3.2.2. La integración a nivel de procesos .................................................................... 19 3.3. Características de un sistema integrado de gestión (ERP) ....................................... 21 3.3.1. Definición de un sistema ERP........................................................................... 21 3.3.2. Estructura de un sistema ERP............................................................................22 3.3.3. Características generales de un ERP ................................................................. 26 Índice de contenidos Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 4 3.4. Criterios para la selección de un sistema ERP ......................................................... 27 3.5. Implantación de un sistema ERP.............................................................................. 27 3.6. SAP R/3.................................................................................................................... 29 3.6.1. El software SAP ................................................................................................29 3.6.2. El producto SAP R/3 .........................................................................................30 CAPITULO 4 - TECNOLOGÍAS EMPLEADAS EN EL PROYECTO............................ 33 4.1. Introducción.............................................................................................................. 33 4.2. Sistemas hardware.................................................................................................... 33 4.2.1. Sistemas hardware empleados en el proyecto ................................................... 35 4.3. Tecnología Cluster de IBM ......................................................................................37 4.3.1. Ventajas de los clústeres.................................................................................... 38 4.3.2. Cómo funciona un clúster.................................................................................. 38 4.3.3. Conceptos básicos de los Clústeres...................................................................39 4.3.4. Elementos de un Clúster.................................................................................... 42 4.4. IBM Cross-site Mirroring (XSM)............................................................................. 44 4.4.1. Introducción a Cross-site Mirroring..................................................................44 4.4.2. Auxiliary Storage Pools (ASP).......................................................................... 44 4.4.3. Independet Auxiliary Storage Pools (IASPs).................................................... 45 CAPÍTULO 5 – DISEÑO DE ARQUITECTURA HARDWARE..................................... 46 5.1. Introducción.............................................................................................................. 46 5.2. Estudio de la infraestructura actual .......................................................................... 46 5.3. Requisitos de disponibilidad deseados .....................................................................48 5.4. Elección de la solución de alta disponibilidad.......................................................... 49 5.4.1. Dimensionamiento Hardware............................................................................ 49 5.4.2. Dimensionamiento Hardware alternativo con actualización de la versión del ERP .....................................................................................................................50 CAPÍTULO 6 – IMPLEMENTACIÓN ARQUITECTURA DE ALTA DISPONIBILIDAD ............................................................................................................................................. 51 6.1. Introducción.............................................................................................................. 51 6.2. Componentes hardware solución final ..................................................................... 51 Índice de contenidos Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 5 6.2.1. Armario Producción .......................................................................................... 52 6.2.2. Armario Desarrollo/Test.................................................................................... 53 6.2.3. Detalle componentes .........................................................................................54 6.3. Listados herramienta de configuración de IBM ....................................................... 57 6.4. Instalación física de los sistemas.............................................................................. 61 6.4.1. Instalación de los componentes en los armarios................................................61 6.4.2. Cableado de los componentes ...........................................................................63 6.5. Configuración de los sistemas y HMC..................................................................... 64 6.5.1. Configuración HMC Producción y HMC Desarrollo/Test................................64 6.5.2. Arranque de sistemas IBM Power..................................................................... 71 6.5.3. Creación de particiones lógicas.........................................................................72 6.5.4. Instalación de sistemas operativos.....................................................................73 6.6. Configuración herramientas Cluster y XSM ............................................................74 6.6.1. Configuraciones previas en los sistemas...........................................................75 6.6.2. Definición nodos del Cluster XSM y activación............................................... 76 CAPÍTULO 7 - CONCLUSIONES..................................................................................... 78 ANEXO A - PROGRAMAS DESARROLLADOS PARA EL PROYECTO.................... 79 ANEXO B - COMANDOS EMPLEADOS PARA LA GESTIÓN DEL CLUSTER......... 89 ANEXO C - DESCRIPCIÓN DETALLADA DE LOS ASP ............................................. 90 ANEXO D - CONSIDERACIONES PARA COPIAS DE SEGURIDAD ......................... 91 ANEXO E - COMANDOS BIBLIOTECA XSMUTIL...................................................... 92 BIBLIOGRAFÍA................................................................................................................. 93 ÍNDICE DE TABLAS......................................................................................................... 94 ÍNDICE DE FIGURAS....................................................................................................... 95 Introducción al proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 6 CAPÍTULO 1 - INTRODUCCIÓN AL PROYECTO 1.1. Motivación En la actualidad los sistemas informáticos de las entidades públicas y privadas son una pieza imprescindible para su correcto funcionamiento. Cada vez más empresas y organismos públicos confían procesos de negocio críticos en sistemas informáticos para mejorar la productividad y disponer de esta información crítica en un tiempo mínimo. Confiar los procesos de negocio en los sistemas informáticos de la organización aporta muchas ventajas pero introduce nuevos puntos de fallo que necesitan estar controlados. Para evitar fallos de servicio en los sistemas informáticos de las organizaciones aparecen los sistemas de alta disponibilidad (HA). Un sistema de alta disponibilidad (HA) está formado por distintos componentes hardware y software que combinados proporcionan acceso de forma ininterrumpida a los procesos de negocio. En la actualidad, el uso de sistemas de alta disponibilidad esta muy extendido en las organizaciones y esto motiva y justifica el presente estudio. 1.2. Objetivo Este estudio pretende servir de introducción a los sistemas de alta disponibilidad (HA). Se abordarán las bases teóricas y los aspectos prácticos de este tipo de sistemas utilizando como ejemplo el diseño e implantación de un sistema real para un entorno productivo. Se identificarán los diferentes problemas que aparecen en un proyecto de este tipo y se plantearán soluciones utilizando como ejemplo el diseño e implantación de un sistema real para un entorno productivo. 1.3. Organización Los primeros capítulos, del 2 al 4, se orientan a introducir conceptos necesarios para abordar un proyecto de alta disponibilidad (HA). El concepto de alta disponibilidad se estudiará profundamente en el segundo capítulo. El tercer capítulo se empleará para describir el sistema de planificación de recursos empresariales (ERP) que será la aplicación principal que va a ejecutarse en el entorno de alta disponibilidad diseñado e implementado a lo largo del proyecto. En el cuarto capítulo se dan a conocer las diversas tecnologías que van a ser empleadas durante el proyecto. El quinto capítulo aborda el diseño de la arquitectura hardware del sistema de alta disponibilidad (HA) desde un punto de vista práctico aplicado a la solución elegida en el proyecto. Introducción al proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 7 Se describe cada uno de los pasos ejecutados en la fase de diseño del proyecto: • Toma de requisitos inicial • Estudio de la infraestructura existente • Elección de la solución de alta disponibilidad • Elaboración de necesidades para la implementación de la solución El sexto capítulo comprende la implementación de la arquitectura de alta disponibilidad en función de las decisiones tomadas en las anteriores fases del proyecto. El concepto de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 8 CAPÍTULO 2 - EL CONCEPTO DE ALTA DISPONIBILIDAD (HA) 2.1. Introducción En el siguiente capítulo se va a realizar una descripción del concepto de alta disponibilidad para facilitar la comprensión de los siguientes apartados del proyecto en los que se diseñará e implementará una solución de alta disponibilidad para una herramienta ERP. Se comenzará definiendo el concepto de alta disponibilidad y el motivo por el que es una herramienta imprescindible para multitud de organizaciones. A continuación, se estudiará la importancia de la determinación de las necesidades de disponibilidad reales del cliente para abordar un proyecto de alta disponibilidad lo más coherente posible. En el siguiente apartado se describirán los distintos niveles de disponibilidad empleando un punto de vista general y un punto de vista cercano al usuario. El último apartado del capítulo se describen aspectos importantes para realizar una correcta planificación para asegurar un nivel determinado de disponibilidad en un sistema. 2.2. Alta Disponibilidad en las organizaciones Un sistema se encuentra disponible si los usuarios pueden realizar operaciones sobre éste (acceder al sistema, someter nuevos trabajos, actualizar o modificar trabajos existentes,…). En la actualidad los departamentos de tecnología de la información de las organizaciones han ganado mayor protagonismo y operaciones de negocio críticas que antes no dependían de estos departamentos ahora lo hacen. Debido a esta tendencia, es necesario asegurar un servicio continuado y de calidad a los procesos de negocio críticos que se ejecutan en los sistemas informáticos de las organizaciones. El concepto de alta disponibilidad comprende un diseño de sistema y la implementación de protocolos asociados que aseguren un cierto nivel de continuidad operacional durante un periodo de tiempo determinado. La disponibilidad de un sistema suele estar medida por año y únicamente tiene en cuenta los cortes de servicio no planificados. No se contemplan las paradas planificadas de los sistemas para el cálculo de la disponibilidad. En niveles muy altos de disponibilidad se pueden introducir estos dos parámetros (paradas planificadas y no planificadas) para el cálculo del valor. El concepto de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 9 2.3. Determinación de las necesidades de disponibilidad del cliente El principal aspecto en el diseño de la disponibilidad de un sistema es obtener los requerimientos reales de disponibilidad de los usuarios. Para obtener esta información es necesario estudiar con detenimiento el modo en el que los usuarios utilizan las aplicaciones de la organización, determinar cuales son críticas y necesitan de una mayor disponibilidad. En este primer estudio del entorno es recomendable que el cliente sea consciente del coste de hacer que un sistema junto con sus aplicaciones sea altamente disponible, ya que como norma general, el coste de un sistema se incrementa exponencialmente conforme aumenta su disponibilidad. Tras realizar el estudio de las necesidades de disponibilidad del cliente, se puede redactar un documento de acuerdo de nivel de servicio. En esta primera fase de estudio el documento únicamente debe reflejar los aspectos relativos a la disponibilidad de los sistemas. Conforme se va avanzando en el diseño de la solución, el documento de acuerdo de nivel de servicio reflejará otros aspectos como el tiempo de respuesta tras un fallo en el sistema, las paradas planificadas necesarias para el correcto mantenimiento del sistema y otros aspectos relativos al rendimiento o calidad del servicio. En la mayoría de los casos, puede obtenerse un alto nivel de disponibilidad implementando los procesos y los métodos de gestión de sistemas adecuados. Cuanta más disponibilidad continuada sea necesaria, mayor será la inversión a realizar. Antes de realizar una inversión de este tipo, es necesario asegurarse que ese nivel de disponibilidad es realmente necesario. En la figura siguiente se muestra cómo distintas técnicas pueden mejorar la disponibilidad, aunque también pueden aumentar el precio que se deberá pagar. Figura 1. Coste de diferentes técnicas para mejorar la disponibilidad El concepto de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 16 las funciones que se ejecutaban en el sistema primario estarán nuevamente disponibles. Esta solución requiere hardware específico de almacenamiento, software y ancho de banda de la red (la replicación síncrona requiere mayor ancho de banda que la replicación asíncrona, ya que no se puede modificar un nuevo dato hasta que no se ha almacenado en el otro sistema). 2.6.7. Caminos de red redundantes o Multipath / Path Failover Una solución de comunicación empleando múltiples caminos garantiza que exista un camino de comunicación cuando se produce la caída del camino principal. Además de la seguridad que introduce el empleo de múltiples caminos de comunicación, existe la posibilidad de configurar el sistema para realizar balanceo de carga. Cuando se produce una acumulación de datos por sobrecarga simplemente se desvía por otro camino con menos actividad, la carga se distribuye de forma automática a través del resto de caminos redundantes de la forma más óptima. Esto puede significar un aumento importante del rendimiento de los sistemas y, adicionalmente, una ganancia en disponibilidad. Figura 3. Esquema de multipath sencillo El concepto de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 17 2.6.8. Clústeres y programas altamente disponibles La principal estrategia de disponibilidad para un entorno de varios sistemas es la utilización de clústeres. Un clúster es una colección o un grupo de varios servidores que funcionan conjuntamente como si se tratara de un único servidor. Si una organización necesita alta disponibilidad o una disponibilidad continuada, se debería considerar la posibilidad de utilizar clústeres. Los servidores de un clúster funcionan en colaboración para proporcionar una única solución de sistemas. Un clúster puede estar compuesto de un número muy elevado de servidores. Esto ofrece la posibilidad de agrupar con eficacia servidores con el fin de establecer un entorno que proporcionará una disponibilidad cercana al 100 por ciento para las operaciones y los datos más importantes. Una configuración en cluster ayuda a garantizar que los servidores y las aplicaciones más importantes están siempre disponibles. Los clústeres también ofrecen una gestión de sistemas simplificada y mayor escalabilidad para poder incorporar nuevos componentes progresivamente a medida que crece la organización. Aunque las ventajas de los clústeres son numerosas, su coste es significativo. Es necesario comparar el coste de esta solución con el coste del tiempo de inactividad del servidor para determinar si se debe implementar o no la utilización de clústeres en una organización. Si se opta por la utilización de clústeres en un entorno, es importante considerar los tipos de aplicaciones que se utilizan en la organización. Existen algunas aplicaciones diseñadas para hacer frente a algunos de los efectos de una anomalía. Como se ha comentado en varias ocasiones, las aplicaciones y los datos son muy importantes para una organización. Si se utilizan clústeres, es recomendable utilizar programas que ofrezcan posibilidad de recuperación ante una interrupción en el sistema. Estas aplicaciones pueden ser diseñadas y/o desarrolladas por el departamento de desarrollo de la organización, pero también pueden adquirirse aplicaciones que satisfagan los criterios necesarios para funcionar en entornos “clusterizados”. Si se opta por diseñar y/o desarrollar los programas personalmente, es necesario orientar el diseño de programas a la posibilidad de recuperación y a que cumplan los niveles de disponibilidad de la organización. Sistemas de planificación de recursos empresariales (ERP) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 18 CAPÍTULO 3 - SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES (ERP) 3.1. Introducción A pesar de que el principal objetivo de este proyecto es el diseño e implementación de una solución de alta disponibilidad, es imprescindible conocer el software que va a ejecutarse en la nueva arquitectura para un mejor entendimiento del proyecto a nivel global. En este caso, el software que va a ejecutarse en el entorno altamente disponible, es un producto ERP (Enterprise Resource Planning) o sistema de planificación de recursos empresariales, en concreto, el producto SAP R/3. En el segundo apartado de este capítulo se va a realizar la descripción de un sistema ERP, un repaso a la evolución de los diferentes productos de gestión empleados por las empresas a lo largo del tiempo y estudiar la necesidad de introducir un sistema ERP en la actualidad. En el tercer apartado de este capítulo se van a definir los sistemas ERP, estudiar como se estructuran este tipo de productos y nombrar sus características más importantes. La selección de un sistema ERP es una decisión importante para las organizaciones. En el cuarto apartado de este capítulo se describen algunos criterios que se consideran vitales para la selección de un producto ERP. En el quinto apartado se describe brevemente un proceso de implantación de un producto ERP en una organización. En el último apartado del capítulo se estudia el producto ERP que se empleará en el proyecto: SAP R/3. 3.2. La necesidad de un software de gestión integral (ERP) El entorno cada vez más competitivo y exigente en el que tienen que desenvolverse actualmente las organizaciones ha obligado a mejorar de forma drástica la gestión y a facilitar la integración de las distintas áreas funcionales, con el objetivo de poder ofrecer un mejor servicio a los clientes, reducir los plazos de entrega, minimizar los inventarios de productos, etc. 3.2.1. La evolución de los sistemas informáticos de gestión Los Sistemas Integrados de Gestión o ERP (Enterprise Resource Planning) surgen en los años noventa como una evolución de los existentes hasta la fecha: sistemas de gestión de inventarios y planificación de la producción, en sus distintas versiones (MRP: Material Requirements Planning, de los años setenta; MRP II: Manufacturing Resources Planning, Sistemas de planificación de recursos empresariales (ERP) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 19 de los años ochenta); programas de contabilidad: aplicaciones de gestión de la facturación, etc. Los sistemas ERP (Enterprise Resource Planning) tienen el objetivo de facilitar la gestión de todos los recursos de la empresa, a través de la integración de la información de los distintos departamentos y áreas funcionales. 3.2.2. La integración a nivel de procesos En la estructura organizativa tradicional de una empresa cada departamento se centra en resolver las tareas que tiene asignadas de manera eficaz y eficiente. En principio, este planteamiento parece el más lógico para mejorar la productividad, ya que se basa en una división y especialización del trabajo, de manera que un determinado departamento se encarga de las actividades comerciales y de marketing, otro se ocupa de toda la gestión financiera y administrativa, etc. La paulatina introducción de la informática en las organizaciones permitió dar soporte a cada uno de estos departamentos y áreas funcionales de forma aislada. Pero, de esta forma, cada departamento se centra en la función que tiene asignada y pierde la visión global de las actividades de la organización. La separación entre las distintas funciones puede dificultar la comunicación entre departamentos y el flujo de actividades que se desarrollan a nivel global por la empresa. Así, por ejemplo, el cliente no va a percibir que el departamento de producción es muy eficiente y rápido entregando los productos si, a la postre, la entrega se ve retrasada por una mala coordinación con el departamento de logística: de poco sirve fabricar bien y rápido si el producto debe esperar unos días en el almacén hasta que alguien se encargue de enviarlo a su destino. Al cliente le interesa el resultado final de la actividad global de la empresa y no el resultado de los trabajos realizados por cada uno de los departamentos. Por este motivo, es necesaria la adopción de una nueva visión del funcionamiento de la empresa, más orientada hacia el cliente y hacia el resultado global: la visión por procesos. El funcionamiento de la empresa desde el punto de vista de los clientes no es una secuencia aislada de actividades, sino, más bien, el resultado de una secuencia coordinada de actividades en las que van a intervenir las distintas unidades organizativas (departamento comercial, departamento de producción, departamento de administración, etc.), es decir, en la empresa se producen flujos de actividades, a las que se denomina procesos, que tienen la característica de atravesar distintas unidades organizativas. Hammer y Champy definen un proceso como un “conjunto estructurado y mesurable de actividades que se desarrollan en una organización con el objetivo de conseguir un resultado concreto para algún cliente o mercado específico”. Un proceso se caracteriza, por lo tanto, por una secuencia de actividades con unos inputs y unos outputs mesurables. Sistemas de planificación de recursos empresariales (ERP) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 20 A la hora de estudiar las actividades que lleva a cabo una empresa, es interesante la observación desde el concepto de la cadena de valor desarrollado por Michael Porter (Gómez Vietes, 2006). Se entiende por valor la cantidad que los clientes están dispuestos a pagar por lo que la empresa proporciona y la cadena de valor es la secuencia de actividades que generan valor para el cliente final. Las actividades de valor se pueden dividir en dos grupos: actividades primarias, implicadas en la creación física del producto y su venta y entrega al comprador, así como la asistencia posterior a la venta, y actividades de apoyo, que sustentan las actividades primarias y se apoyan entre sí (actividades administrativas, de I + D, de sistema de información, de gestión de recursos humanos, etc.). Con el enorme avance experimentado por las Tecnologías de la Información en estos últimos años, la capacidad existente para capturar, procesar, almacenar y distribuir la información se ha incrementado de manera exponencial y se han eliminado las barreras espaciales y temporales que en muchos casos dificultaban la coordinación entre las distintas funciones de la empresa. Los sistemas ERP permiten integrar los flujos de información de los distintos departamentos de la empresa, facilitando el seguimiento de las actividades que constituyen la cadena de valor. Es necesario tener en cuenta que la cadena de valor sobrepasa los límites de la empresa, ya que incluye tanto a las actividades realizadas por los proveedores, como a las propias del canal de distribución. De esta forma, se produce una integración vertical de actividades hasta llegar al cliente final. La satisfacción del cliente dependerá del resultado completo de la cadena de valor y, por lo tanto, no llega con gestionar eficaz y eficiente las actividades de la empresa, sino que es necesario tener en cuenta la gestión global de la cadena de valor, en estrecha relación con los proveedores y con el canal de distribución. Por este motivo, los modernos sistemas ERP incluyen el soporte y la integración de las actividades de los proveedores y los distribuidores: SCM (Supply Chain Management) y CRM (Customer Relationship Management). En la gestión por procesos el énfasis se centra en qué, cómo, por qué y para quién se hacen las cosas y no tanto en el quién las hace, es decir, la empresa desplaza su punto de mira desde el producto hacia el cliente, ya que la clave de su éxito está en generar valor y mejorar la satisfacción del cliente. Podemos considerar que el producto (o, en su caso, la prestación de servicio) es el medio que permite a la empresa alcanzar el fin que garantiza su éxito en el mercado: ofrecer valor al cliente. No existe unanimidad a la hora de identificar los principales procesos de la empresa. John Sviokla y otros investigadores de Harvard sostienen que sólo hay dos procesos principales: gestionar la línea de productos y gestionar el ciclo de pedidos. Sistemas de planificación de recursos empresariales (ERP) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 21 Por su parte, John Rockart y James Short, de la MIT Sloan School Management, defienden que son tres los procesos principales: desarrollo de nuevos productos, entrega de los productos a los clientes y gestión de las relaciones con los clientes (Gómez Vietes, 2006). La mayoría de las empresas han identificado entre 10 y 20 procesos clave. En la siguiente tabla se presentan varios procesos típicos para una empresa de fabricación: Procesos operativos Procesos de gestión • Diseño y desarrollo de nuevos productos • Captación de clientes • Identificación de los requerimientos de los clientes • Fabricación • Logística integrada • Gestión de pedidos • Servicio de postventa • Control del funcionamiento y resultado • Gestión de recursos humanos • Gestión de la información • Gestión de activos • Planificación y asignación de recursos Tabla 2. Procesos típicos en empresas de fabricación 3.3. Características de un sistema integrado de gestión (ERP) 3.3.1. Definición de un sistema ERP Los sistemas de gestión ERP surgieron con el objetivo de facilitar un sistema que cubriera todas las áreas funcionales de una empresa de forma integrada: finanzas, producción, compras, ventas, recursos humanos, etc. Hasta la presentación en el mercado de estos sistemas ERP, se solía utilizar un software independiente para cada departamento, dando lugar a múltiples problemas derivados de la dispersión de datos y formatos, que dificultaban la integración de la información: la típica situación de “islas de información” que no se podían interconectar. Se puede definir un sistema ERP como un sistema integrado de software de gestión empresarial, compuesto por un conjunto de módulos funcionales (logística, finanzas, recursos humanos, etc.) susceptibles de ser adaptados a las necesidades de cada cliente. Un sistema ERP combina la funcionalidad de los distintos programas de gestión en uno solo, basándose en una única base de datos centralizada. Esto permite garantizar la integridad y unicidad de los datos a los que accede cada departamento, evitando que éstos tengan que volver a ser introducidos en cada aplicación o módulo funcional que los requiera (así, por ejemplo, si una factura ha sido registrada en el módulo de clientes, ya no es necesario introducirla de nuevo en el módulo de contabilidad y finanzas). Un sistema de estas características debería estar adaptado para funcionar en entornos internacionales, soportando la gestión de varios idiomas, monedas y sistemas de tributación, así como la generación de informes y documentos adaptados a la legislación Sistemas de planificación de recursos empresariales (ERP) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 22 vigente en cada país. Se trata de un importante aspecto a tener en cuenta, dada la diversidad de normas existentes y las variaciones que sufren a lo largo del tiempo. Por otra parte, ante la demanda por parte del mercado de soluciones específicas para los diferentes sectores industriales o de servicios, los proveedores de sistemas ERP han desarrollado productos especializados que incorporan aplicaciones y funcionalidades a la medida de un determinado sector, denominadas soluciones “verticales” o “sectoriales”. 3.3.2. Estructura de un sistema ERP EL SISTEMA BÁSICO DE UN ERP La mayoría de los ERPs adoptan una estructura modular que soporta los diferentes procesos de una empresa: el módulo de gestión financiera, el módulo de gestión de compras, el módulo de gestión de ventas, el módulo de recursos humanos, etc. Todos estos módulos están interconectados y comparten una base de datos común, garantizando de este modo la coherencia e integración de los datos generados. El hecho de que estos productos sean modulares posibilita la implantación del sistema por etapas, reduciendo el impacto global en la organización al facilitar la transición desde los sistemas anteriores. Normalmente, el primer módulo que se pone en marcha es el financiero y, posteriormente, se van integrando los restantes, dependiendo de las características particulares de cada empresa. El sistema básico del ERP está formado por las aplicaciones técnicas y la arquitectura necesaria para servir de plataforma al resto de los módulos. Proporciona herramientas de administración para controlar tanto el sistema en sí (rendimiento, comunicación con otras aplicaciones y otros sistemas, etc.), como la base de datos que constituye el núcleo del producto. Las principales plataformas de servidores son OS 400, UNIX y Windows 2003 mientras que las bases de datos más utilizadas son Oracle, IBM DB2 y Microsoft SQL Server. Asimismo, la mayor parte de los sistemas ERP disponen de lenguajes de programación propietarios de cuarta generación (4GL), que facilitan el desarrollo y adaptación de aplicaciones a la medida de cada cliente. Por otra parte, las últimas versiones de los ERPs incluyen el soporte a las tecnologías derivadas de Internet, como el estándar XML o el lenguaje de programación JAVA. Sistemas de planificación de recursos empresariales (ERP) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 23 Cada proveedor de ERP define la modularización de su solución, atendiendo a razones comerciales o técnicas. En la tabla siguiente se muestra, a modo de ejemplo, la modularización del ERP SAP R/3: Procesos principales Módulos de SAP R/3 Gestión financiera y control Finance Treasure Management Enterprise Controling Invest Management Aprovisionamiento y logística interna Material Management Ventas y logística externa Sales and Distribution Producción Production Planning Gestión de medios técnicos Plant Maintenance Gestión de recursos humanos Human Resources Tabla 3. Relación de procesos con módulos de un ERP Seguidamente, se muestran algunas de las funcionalidades incluidas en los principales módulos que constituyen un sistema ERP. MÓDULO DE APROVISIONAMIENTO El proceso de aprovisionamiento en una empresa comprende la gestión de materiales y la relación con los proveedores. En el apartado de gestión de materiales el sistema debe dar soporte a la definición de los datos necesarios para el tratamiento de los materiales a lo largo de toda la cadena logística, así como las transacciones realizadas con ellos, facilitando el control de los stocks, la generación de nuevos pedidos, la valoración de inventarios de acuerdo con distintos criterios, etc. En lo que se refiere al apoyo a la relación de la empresa con los proveedores, el sistema debe proporcionar toda la información sobre precios y condiciones de entrega, historial de compras, disponibilidad, etc., facilitando de este modo el proceso de toma de decisiones de compra. Asimismo, mediante distintas opciones de análisis, el sistema puede realizar una valoración de los proveedores: cumplimiento de plazos de entrega, estado de los materiales, fiabilidad, etc. Este módulo se apoya en dos bases de datos fundamentales: • La base de datos de materiales, que permite registrar para cada referencia su código, descripción, peso, dimensiones, calidad, cantidad en stock, etc. • La base de datos de proveedores, que almacena los datos sobre cada uno de los proveedores seleccionados: nombre, personas de contacto, dirección de pedido, datos fiscales para facturación, etc., así como precios y condiciones de entrega de los productos que ofrece. Sistemas de planificación de recursos empresariales (ERP) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 24 El módulo de aprovisionamiento facilita la planificación de los pedidos a proveedores a partir de las necesidades de compra de la empresa, que pueden venir determinadas por la demanda de productos terminados o por el control de unos stocks mínimos de producción. Además, este módulo puede ofrecer la posibilidad de consultar el historial de los proveedores y de los movimientos de materiales que se han realizado. En definitiva, el módulo de aprovisionamiento deberá dar soporte a todos los procesos de compra, desde la gestión de proveedores y tarifas hasta el control de los procesos de pedidos, conciliación de facturas y otras fases implicadas en el aprovisionamiento, tanto de productos como de materias primas, bienes de inversión o servicios, así como la gestión de contratos de suministro. MÓDULO DE PRODUCCIÓN El módulo de producción se encarga gestionar los materiales y servicios empleados en la cadena de producción de una empresa, así como los recursos (máquinas, utillaje, personal) utilizados en ésta. Este módulo facilita la planificación de los materiales y de las capacidades de los recursos, lanzando las órdenes de montaje o de fabricación y adaptándose a las características específicas de los distintos sistemas de fabricación: fabricación contra stock, fabricación a medida contra pedido (build to order) o montaje (únicamente se realiza el ensamblaje final de las distintas piezas que componen el producto). Para contribuir a una adecuada gestión de los stocks de materiales, este módulo debe estar totalmente integrado con el módulo de aprovisionamientos. Además este módulo puede incorporar diferentes funcionalidades adicionales como la planificación a capacidad finita, la captura de datos de planta, la gestión de subcontrataciones, etc. MÓDULO DE VENTAS El módulo de ventas se ocupa de la relación de la empresa con los clientes, dando soporte a todas las actividades comerciales preventa (contactos, presupuestos…) y posventa (entrega, factura, devoluciones…). Asimismo, facilita la gestión y configuración de los pedidos, la logística de distribución, la preparación de entregas, la expedición y el transporte. Para un correcto funcionamiento, el módulo de ventas deberá estar integrado con los módulos de almacén, logística, módulo financiero, etc. Asimismo, cada vez se exige un mayor nivel de integración entre ventas y compras, reflejo de una progresiva orientación a una operativa “bajo pedido”. MÓDULO DE FINANZAS El módulo de finanzas se encarga de la contabilidad y de la gestión financiera de la empresa. Se trata de un módulo esencial dentro del sistema ERP, ya que va a estar totalmente integrado con los restantes módulos. Por este motivo, resulta fundamental para la correcta implantación del ERP. Sistemas de planificación de recursos empresariales (ERP) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 25 Este módulo proporciona herramientas flexibles y aplicaciones orientadas tanto a la contabilidad financiera, como a contabilidad analítica o de costes. Entre sus múltiples funciones relacionadas con la operativa financiera y contable destacan las siguientes: • Contabilización de las operaciones de la empresa (generación de asientos contables). • Elaboración de los balances y de la cuenta de resultados. • Elaboración de presupuestos, generación de informes y análisis de desviaciones. • Gestión de la tesorería (control de flujos de cobros y pagos, gestión de cuentas corrientes, líneas de crédito y de depósitos, etc.). • Gestión de activos Asimismo, este módulo proporciona funciones específicas para el departamento de administración de una empresa: • Facturación (emisión de facturas). • Liquidación de los impuestos (sobre Sociedades, IVA, etc.). • Gestión de cobros y reclamación de impagados. En general, todos los sistemas ERP disponen de un gran número de informes financieros y contables estándar e incorporan herramientas de diseño a medida para facilitarles la generación de informes adaptados a las necesidades de cada cliente, como en el caso de la liquidación de impuestos a cada país. MÓDULO DE RECURSOS HUMANOS El módulo de recursos humanos de un ERP permite la gestión de la información relacionada con los empleados de una organización (datos personales, formación recibida, experiencia, ocupación, salario, historial profesional, períodos vacacionales, bajas por enfermedad, premios, sanciones, etc.). Entre las múltiples funciones que facilita podemos destacar las siguientes: • Definición de estructuras organizativas • Planificación de las necesidades de personal • Soporte al proceso de evaluación y selección de personal (registro de currículo vitae, gestión de pruebas de evaluación, clasificación de candidaturas, etc.) • Control de presencia (gestión de turnos de trabajo y de horarios, así como de períodos vacacionales, bajas por enfermedad, permisos, etc.), relacionado generalmente con el módulo de producción. • Soporte a la contratación de personal (registro y modificación de los distintos tipos de contratos laborales) • Gestión de las acciones formativas • Registro de los gastos de representación y de dietas por desplazamientos • Soporte a la generación de nóminas Sistemas de planificación de recursos empresariales (ERP) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 32 tanto, lo anterior no requerirá producir o tramitar copias de papeles de la compra y/o facturarla para el uso de varios departamentos administrativos, sino que tendrán la información necesaria en el sistema. Una vez recibido el ventilador industrial, el departamento notificará del hecho al sistema SAP R/3 y se pagará la factura sin la necesidad de aprobaciones futuras. La oficina central de contabilidad puede hacer los cálculos por cargos extras. La oficina de activos, a través del sistema R/3 sabe que el ventilador fue entregado y desde ese momento puede empezar a hacer el cálculo de las depreciaciones. La oficina de mantenimiento también estará enterada del hecho y comenzará a hacer el calendario de mantenimiento para el ventilador, así se realiza un historial del ventilador fácilmente. INTEGRACIÓN DE LOS DATOS DE APLICACIÓN Debido a la integración, en cada modificación en un módulo de aplicación se actualizan automáticamente los datos del otro módulo de aplicación afectado. La actualización de los datos registrados se efectúa en la base de datos utilizada en común por las aplicaciones. Todos los módulos de aplicación disponen de una arquitectura y una interfaz de usuario común. • Proceso interactivo: Las entradas de los usuarios se procesan de modo interactivo por el Sistema R/3 y se verifican para garantizar la consistencia de los datos. • Integración de varios idiomas en tiempo real: En la aplicación pueden trabajar varios usuarios simultáneamente en idiomas diferentes, porque el Sistema R/3 actualiza la adaptación de los datos registrados en idiomas diferentes durante el tiempo de operación. El Sistema R/3 se entrega en todos los idiomas ampliamente extendidos. También en kanji y mandarín, mediante la reproducción de los símbolos por el procedimiento Doble-Byte. Tecnologías empleadas en el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 33 CAPITULO 4 - TECNOLOGÍAS EMPLEADAS EN EL PROYECTO 4.1. Introducción En este capítulo se van a describir las tecnologías empleadas en el proyecto en función de las necesidades y a justificar su elección frente al resto de opciones disponibles en el mercado. El primer apartado es un trabajo previo a la fase de diseño en el que mencionan algunos aspectos a tener en cuenta para la elección de la arquitectura hardware. En base a esto se decide la arquitectura hardware del proyecto. En la fase de diseño se describirán con detalle cada uno de los elementos hardware empleados en el proyecto. En el siguiente apartado se definirá brevemente la tecnología cluster y en concreto la tecnología cluster empleada en el proyecto. En el último apartado del capítulo se introduce la tecnología IBM Cross-site Mirroring necesaria para obtener un Cluster de alta disponibilidad. 4.2. Sistemas hardware La elección del proveedor principal de los componentes hardware para un proyecto de alta disponibilidad es una decisión importante. Como norma general, la inversión económica inicial necesaria para este tipo de proyectos es muy importante y la elección realizada en el primer momento se suele arrastrar durante el tiempo necesario para amortizar el desembolso. Existen varios aspectos importantes que se deben tener en cuenta para elegir correctamente: • Sistemas instalados actualmente • Ciclo de vida de los sistemas existentes • Conocimientos de los empleados del departamento de Tecnologías de la Información SISTEMAS INSTALADOS ACTUALMENTE Los sistemas instalados actualmente pueden ser un factor decisivo para elegir el hardware para el proyecto de alta disponibilidad. En concreto, los sistemas en los que se ejecuta actualmente el software vital que se desea proteger con el nuevo sistema. Elegir el mismo tipo de hardware puede evitar tener que realizar costosas adaptaciones en el software para que se ejecuten en el nuevo entorno. Esto se observa con mayor claridad Tecnologías empleadas en el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 34 cuando los sistemas emplean arquitecturas diferentes como x86 o PowerPC de IBM, ya que en estos casos es posible que sea necesario reescribir el código del software (si es un desarrollo propio) o no exista versión del software para otro tipo de arquitectura hardware, con lo que la migración a los nuevos sistemas puede ser muy complicada. En este proyecto en particular, los sistemas hardware que ejecutan las aplicaciones de producción son sistemas IBM Power en los que se ejecuta el sistema operativo i5/OS en la versión V5R2. El software ERP que se desea migrar al nuevo entorno de alta disponibilidad está preparado para ejecutarse sobre este tipo de sistemas así como los desarrollos propios realizados sobre los módulos del software ERP. Para valorar las posibles alternativas hardware se puede emplear una tabla como la siguiente: Costes según sistema Concepto Opción 1 Opción 2 Opción 3 Hardware HA Software HA Implantación Migración ERP Formación Total Tabla 4. Costes de los diferentes sistemas La valoración que se puede realizar empleando la tabla anterior es principalmente económica. Se da por supuesto que los diferentes sistemas de distintas marcas cumplen con los requisitos de calidad exigidos por el cliente (el hardware sea redundante, el software HA se ejecute correctamente sobre los sistemas,…). CICLO DE VIDA DE LOS SISTEMAS EXISTENTES El mantenimiento de los sistemas críticos de las organizaciones es un aspecto que no se puede dejar al azar. En caso de un incidente en cualquiera de estos sistemas que comprometa el servicio es necesario volver a restaurarlo en el menor tiempo posible. Las principales compañías proveedoras de sistemas hardware disponen de contratos de mantenimiento para las máquinas entregadas. Con estos contratos se comprometen a sustituir las piezas dañadas o incluso el sistema por completo, en caso de fallo. Existen diferentes modalidades con la principal diferencia del tiempo de respuesta ofrecido y de la duración. Un ejemplo de contrato de mantenimiento es el ServicePac de IBM: • Rango de duración de entre 1 y 5 años desde la fecha de compra del sistema. Tras la finalización es posible su renovación. • Horarios de cobertura desde 9x5 (9 horas al día durante cinco días a la semana) hasta 24x7 (24 horas al día durante los siete días de la semana). • Diferentes niveles de servicio de reparación (en el mismo día laborable o el siguiente día laborable). El precio de contratar estos servicios suele ser elevado y conforme los sistemas van envejeciendo el precio se dispara. A partir de una cierta antigüedad los sistemas se retiran Tecnologías empleadas en el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 35 de la venta e incluso se elimina la posibilidad de contratar el mantenimiento para estos sistemas. CONOCIMIENTOS DE LOS EMPLEADOS DEL DEPARTAMENTO DE TECNOLOGÍAS DE LA INFORMACIÓN Un aspecto imprescindible que es necesario tener en cuenta es el nivel de conocimientos de los empleados del departamento de Tecnologías de la Información, es decir, de las personas encargadas de administrar la nueva infraestructura. En ocasiones la elección de los nuevos sistemas está directamente relacionada con los conocimientos del personal encargado de su manejo. Si los administradores no reciben la correcta formación (si el sistema es nuevo) es posible que no se encuentren cómodos con la nueva implantación y esta sea un fracaso. Por este motivo es necesario tener siempre en cuenta los conocimientos de los administradores y considerar si las ventajas que se consiguen con los nuevos sistemas justifican la inversión en formación e incluso la contratación de personal nuevo. 4.2.1. Sistemas hardware empleados en el proyecto En este proyecto se han empleado sistemas IBM System i Power 6 en los que se ejecuta el sistema operativo i5/OS en la versión V6R1. Antes de realizar la migración la empresa ya empleaba sistemas IBM System i para las tareas de producción. La decisión de continuar con máquinas de IBM se debe a varios de los puntos indicados en el apartado anterior. COMPATIBILIDAD CON LOS SISTEMAS ANTIGUOS Para implementar la solución de alta disponibilidad con el menor impacto sobre la infraestructura existente se ha optado por emplear la misma tecnología en los nuevos sistemas. De este modo no es necesario realizar excesivas modificaciones en las configuraciones de los nuevos sistemas y del software que se va a desplegar en el nuevo entorno. Tras analizar de los productos software que se ejecutan en las máquinas antiguas es necesario comprobar que estos pueden ejecutarse sin problemas en las nuevas máquinas y soportan la funcionalidad de alta disponibilidad. En este proyecto de migración no se encontraron incompatibilidades y todo el software crítico que se emplea en la organización dispone de versiones compatibles con los nuevos sistemas hardware. Los nuevos sistemas IBM System i Power 6 se introducen en la plataforma para sustituir a los antiguos sistemas IBM System i Power 5 (modelo 810). Los nuevos sistemas son compatibles con tecnologías de alta disponibilidad. Tecnologías empleadas en el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 36 COSTE DEL MANTENIMIENTO DE LOS SISTEMAS ANTIGUOS El coste del mantenimiento de los sistemas va aumentando conforme van apareciendo nuevos sistemas que sustituyen a los anteriores. Llega el momento en el que se retira de mantenimiento el sistema antiguo y con ello la posibilidad de conseguir recambios certificados por el fabricante. Para aclarar este punto es necesario indicar que un sistema puede estar retirado de “Marketing” (no se puede comprar) pero el fabricante continúa ofreciendo recambios durante un periodo de tiempo determinado. La siguiente imagen muestra la planificación de IBM en el lanzamiento de sus procesadores Power: Figura 6. Fechas de lanzamiento de los procesadores IBM Power En este proyecto el coste del mantenimiento de los sistemas hardware se había incrementado sustancialmente debido a la antigüedad de los mismos hasta el punto de que la inversión en los nuevos sistemas (sin incluir el mantenimiento) se recuperaba al cabo de cinco años. Es decir, el coste del mantenimiento de los sistemas antiguos durante los próximos cinco años era superior al coste de adquisición de los nuevos sistemas. Los sistemas operativos de IBM tienen también fechas de mantenimiento y salida al mercado. En la siguiente figura se muestra el ciclo de vida de los sistemas operativos para IBM System i: Tecnologías empleadas en el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 37 Figura 7. Ciclo de vida de IBM i El sistema operativo que inicialmente ejecutaban los sistemas antiguos era el IBM i5/OS V5R2. Se realizaron actualizaciones frecuentemente hasta llegar al máximo nivel de sistema operativo soportado por las máquinas antiguas (Power 5). Tras realizar los cálculos pertinentes (económicos, rendimiento, fiabilidad, etc…) se llegó a la conclusión de sustituir los sistemas hardware antiguos IBM System i Power 5 por nuevos sistemas IBM System i Power 6 con la nueva versión del sistema operativo i5/OS V6R1. CONOCIMIENTO DE LOS EMPLEADOS DEL DEPARTAMENTO DE TECNOLOGÍAS DE LA INFORMACIÓN El departamento de Tecnologías de la Información de esta organización tiene gran experiencia en el manejo de sistemas IBM System i. La implantación de la nueva infraestructura permite aprovechar las habilidades del personal para llevar a cabo la migración con garantías de éxito. A pesar de las habilidades del personal de la organización es necesario realizar formación en varias herramientas nuevas que no estaban acostumbrados a manejar con anterioridad: • HMC (Hardware Management Console) • Tecnología Cluster La adquisición de estas nuevas habilidades es muy rápida dado el nivel de conocimiento de los empleados de los sistemas IBM System i. 4.3. Tecnología Cluster de IBM Un clúster de System i es una colección o grupo compuesto por uno o más sistemas o particiones lógicas que funcionan juntos como un solo servidor. Los sistemas de un clúster, conocidos como nodos del clúster, trabajan en conjunto para facilitar una solución informática individual. Tecnologías empleadas en el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 38 Un clúster de System i admite hasta 128 nodos. Esto permite agrupar de un modo eficaz los sistemas System i para configurar un entorno que proporcione disponibilidad y se ajuste completamente a las aplicaciones y datos críticos. De este modo es posible asegurar que sistemas y aplicaciones críticas están disponibles 24 horas al día, siete días a la semana. Los clústeres también proporcionan una gestión simplificada de sistemas y una mayor escalabilidad para permitir la adición sin fisuras de componentes nuevos según las necesidades de crecimiento empresarial. 4.3.1. Ventajas de los clústeres Los clústeres ofrecen una solución para las organizaciones que necesitan entornos operativos durante 24 horas diarias, siete días a la semana. Mediante la utilización de clústeres, es posible reducir significativamente el número y la duración de interrupciones no planificadas y la duración de las interrupciones planificadas, garantizando la disponibilidad continua de los sistemas, datos y aplicaciones. Las principales ventajas que pueden ofrecer un clúster a una organización: • Disponibilidad continua: Los clústeres aseguran la disponibilidad continua de los sistemas, datos y aplicaciones. • Administración simplificada: Es posible administrar un grupo de sistemas como un solo sistema o una sola base de datos, sin necesidad de conectar a cada uno de los sistemas individualmente. Se puede utilizar un dominio administrativo de clúster para gestionar con mayor facilidad los recursos que se comparten en un clúster. • Mayor escalabilidad: Permite la adición sin fisuras de nuevos componentes según las necesidades de crecimiento de la organización. 4.3.2. Cómo funciona un clúster La infraestructura de clúster aumenta la seguridad para los recursos críticos. Estos recursos pueden incluir datos, aplicaciones, dispositivos y otros recursos a los que acceden múltiples clientes. Si se produce una interrupción del sistema o un siniestro en las instalaciones, puede accederse a las funciones proporcionadas en un sistema del clúster a través de otros sistemas que se han definido en el clúster. Existen dos modelos de acceso a estos datos: • Modelo de copia de seguridad primaria • Modelo de iguales Estos conceptos serán explicados con más detalle durante el capítulo. Tecnologías empleadas en el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 39 4.3.3. Conceptos básicos de los Clústeres Antes de empezar a diseñar y personalizar un clúster que se ajuste a las necesidades de una organización, es necesario entender algunos conceptos básicos de los clústeres. Existen dos conceptos básicos relacionados con los clústeres: • Nodos de clúster. • Grupo de recursos de clúster. Un nodo de clúster es un sistema System i o una partición lógica que sea miembro del clúster. Cuando se crea un clúster, se especifican los sistemas o particiones lógicas que se desea incluir en el clúster como nodos. Un grupo de recursos de clúster (CRG o Cluster Resource Group) se utiliza como el objeto de control para una colección de recursos de recuperación. Un CRG puede contener un subconjunto o todos los nodos del clúster. Un clúster de System i soporta cuatro tipos de CRG: de aplicación, de datos, de dispositivos y de iguales. En estos tipos de CRG hay dos elementos comunes: • Dominio de recuperación. • Programa de salida. Un dominio de recuperación define el cometido de cada nodo en el CRG. Cuando se crea un CRG en un clúster, el objeto CRG se crea en todos los nodos especificados que deben incluirse en el dominio de recuperación. Sin embargo, se facilita una sola imagen del sistema del objeto CRG, a la que puede acceder desde cualquier nodo activo en el dominio de recuperación del CRG. Es decir, cualquier cambio que se introduzca en el CRG, se aplicará a todos los nodos del dominio de recuperación. Se llama a un programa de salida durante los eventos del CRG relacionados con el clúster. Uno de estos eventos es pasar un punto de acceso de un nodo a otro . Existen dos modelos de CRG que se pueden crear en un clúster: modelo de copia de seguridad primaria y modelo de iguales. En el modelo de copia de seguridad primaria, los nodos del dominio de recuperación del CRG se pueden definir como se indica a continuación: • El nodo primario es el nodo de clúster que sirve de punto primario de acceso para un recurso de clúster. • Un nodo de reserva es un nodo de clúster que asumirá el cometido de servir de acceso primario si el nodo primario actual sufre una anomalía, o si se inicia una conmutación manual por administración. • Un nodo de duplicación es un nodo de clúster que contiene copias de los recursos de un clúster, pero que no puede asumir el cometido de nodo primario o nodo de reserva. Tecnologías empleadas en el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 40 En un modelo de iguales, el dominio de recuperación de un CRG de iguales define una relación de igualdad entre nodos. Los nodos del dominio de recuperación del CRG de iguales se pueden definir como se indica a continuación: • Un nodo igual es un nodo de clúster que puede ser un punto de acceso activo para recursos de clúster. • Un nodo de duplicación es un nodo de clúster que contiene copias de los recursos de un clúster. Los nodos definidos como duplicados en un CRG de iguales representan el punto de acceso inactivo de los recursos del clúster. En un CRG de iguales, los nodos del dominio de recuperación son equivalentes en relación con el cometido que juegan los nodos en la recuperación. Puesto que cada nodo de este CRG de iguales tiene esencialmente el mismo cometido, los conceptos de sustitución por anomalía y conmutación de traspaso no son aplicables. Los nodos tienen una relación de igualdad y cuando uno de los nodos falla, los demás nodos iguales seguirán operando. En la siguiente figura se muestran los diferentes tipos de CRG que se pueden crear: Figura 8. Tipos de CRG CRG DE DATOS El CRG de datos está presente en el Nodo 1, el Nodo 2 y el Nodo 3. Ello significa que el dominio de recuperación del CRG de datos ha especificado un cometido para el Nodo 1 (primario), el Nodo 2 (primer nodo de reserva) y el Nodo 3 (segundo nodo de reserva). En el ejemplo, el Nodo 1 actúa como el punto primario de acceso. El Nodo 2 está definido como el primer nodo de reserva en el dominio de recuperación. Ello significa que el Nodo Tecnologías empleadas en el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 41 2 contiene una copia del recurso que se mantiene actual mediante la duplicación lógica. Si se produjera una conmutación por anomalía o por administración, el Nodo 2 se convertiría en el punto primario de acceso. CRG DE APLICACIÓN El CRG de aplicación está presente en el Nodo 4 y el Nodo 5. Ello significa que el dominio de recuperación para el CRG de aplicación ha especificado el Nodo 4 y el Nodo 5. En el ejemplo, el Nodo 4 actúa como el punto primario de acceso. Si se produjera una conmutación por anomalía o por administración, el Nodo 5 se convertiría en el punto primario de acceso para la aplicación. Requiere una dirección IP de toma de control. CRG DE IGUALES El CRG de iguales está presente en el Nodo 6 y el Nodo 7. Ello significa que el dominio de recuperación del CRG de iguales ha especificado el Nodo 6 y el Nodo 7. En este ejemplo, los nodos 6 y 7 pueden ser nodos iguales o duplicados. Si se trata de un dominio administrativo de clúster representado por un CRG de iguales, los recursos supervisados por el dominio administrativo de clúster tendrán sincronizados los cambios en el dominio representado por el nodo 6 y el nodo 7, sea cual sea el nodo en el que se ha originado el cambio. CRG DE DISPOSITIVO El CRG de dispositivo está presente en el Nodo 2 y el Nodo 3. Ello significa que el dominio de recuperación para el CRG de dispositivo ha especificado el Nodo 2 y el Nodo 3. En el ejemplo, el Nodo 2 actúa como el punto primario de acceso. Por lo tanto, actualmente puede accederse al dispositivo del CRG de dispositivo desde el Nodo 2. Si se produjera una conmutación por anomalía o por administración, el Nodo 3 se convertirá en el punto primario de acceso para el dispositivo. Un CRG de dispositivo requiere la configuración de un dispositivo conocido como agrupación de discos independiente (o también agrupación de almacenamiento auxiliar independiente o ASP independiente), en un dispositivo externo, una unidad de expansión (torre) o un procesador de entrada/salida (IOP) en una partición lógica. Los nodos del dominio de recuperación de un CRG de dispositivo también deben ser miembros del dominio del mismo dispositivo. El siguiente ejemplo ilustra un CRG de dispositivo con el Nodo L y el Nodo R en su dominio de recuperación. Ambos nodos son también miembros del mismo dominio de dispositivo. Diseño de arquitectura hardware Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 48 • Memoria instalada: 6 GB • Versión SAP: SAP R/3 4.7 x100 Kernel 6.20 En la siguiente tabla se muestra un resumen de la carga del sistema DESA-TEST (Desarrollo y Test) antes de realizar la actualización: ENTORNO TEST Usuarios nominales Máx. Usuarios concurrentes Concurrencia 15 7 47% Pico de pasos de diálogo por hora: 1.123 Tamaño de Base de Datos: 174 GB Tabla 8. Carga del entorno de Desarrollo ENTORNO DESARROLLO Usuarios nominales Máx. Usuarios concurrentes Concurrencia 12 6 50% Pico de pasos de diálogo por hora: 1.301 Tamaño de Base de Datos: 187 GB Tabla 9. Carga del entorno de Test 5.3. Requisitos de disponibilidad deseados Los requerimientos de disponibilidad han estado presentes durante todo el proyecto. En esta organización el servicio se presta entre departamentos internos de la misma. La instalación de la infraestructura la lleva a cabo una empresa externa pero el mantenimiento y explotación queda a cargo de la organización inicial. El personal del departamento de Tecnologías de la Información es el encargado de reunirse con los responsables del resto de departamentos usuarios del servicio y obtener las necesidades de disponibilidad. Tras recoger las necesidades se realiza un estudio de coste y viabilidad que se transmitirá a la dirección de la organización para su posterior aprobación. En función los requisitos de disponibilidad consensuados entre los diferentes departamentos de la organización se realizan consultas a empresas externas por soluciones que permitan cumplir los requisitos de disponibilidad y coste aprobados por la dirección de la organización. A continuación se enumeran los principales requisitos de disponibilidad: • Disponibilidad de 99,9% = 43.8 minutos/mes u 8,76 horas/año ("tres nueves") en horario de actividad. • Paradas planificadas de los sistemas todos los domingos. • Pruebas del sistema de alta disponibilidad semestralmente con posibilidad de parada de servicio. Diseño de arquitectura hardware Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 49 La solución de alta disponibilidad debe de asegurar que se cumplan estos requisitos. 5.4. Elección de la solución de alta disponibilidad En el capítulo cuarto del proyecto se estudiaron las diferentes tecnologías empleadas en el proyecto: • Componentes hardware (IBM System i Power 6) • Componentes software (IBM Cross-site Mirroring o XSM) En el capítulo cuarto se exponían las razones de la elección de sistemas hardware de IBM para el proyecto: • Compatibilidad con los sistemas antiguos • Coste de mantenimiento de los sistemas antiguos • Conocimiento de los empleados del departamento de Tecnologías de la Información La herramienta software de alta disponibilidad elegida (IBM Cross-site Mirroring o XSM) es un componente más dentro del sistema operativo. Esta elección hace más simple la solución ya que no es necesario hacer funcionar productos de terceros en el sistema operativo. 5.4.1. Dimensionamiento Hardware Puesto que el ERP que va a ejecutarse en los nuevos sistemas es SAP se ha decidido medir el rendimiento del sistema en unidades SAP (SAP Application Performance Standard). Los SAPS son una unidad de medida independiente del hardware, que describen el rendimiento de un sistema en un entorno SAP. En términos técnicos, 100 SAPS equivalen a 2000 procesos de negocio completos por hora. El cálculo de los SAPS que se están consumiendo actualmente en los tres entornos considerados está basado en la premisa de que la instalación cuenta con un Kernel optimizado y en la utilización de los procesadores instalados. De esta manera, • Considerando una utilización actual de CPU del 85%, el entorno de Producción estaría consumiendo actualmente alrededor de 1300 SAPS. • Considerando una utilización de CPU del 75%, los entornos de Test y Desarrollo estarían consumiendo alrededor de 878 SAPS, cada uno de ellos. Se supone que toda la carga actual de los servidores corresponde a los sistemas SAP, aparte de la carga propia del sistema operativo. Se asume que no se va a realizar un cambio en el diseño de la arquitectura, es decir, continuará siendo un diseño en 2 niveles (base de datos y servidor de aplicaciones en el mismo servidor o LPAR). Diseño de arquitectura hardware Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 50 Se asume que no habrá desarrollos adicionales o nuevas cargas (nuevos módulos, nuevas transacciones, etc.) que impacten en las necesidades de capacidad de proceso de los servidores. Se considera alta disponibilidad exclusivamente para el entorno de producción. 5.4.2. Dimensionamiento Hardware alternativo con actualización de la versión del ERP Para el dimensionamiento del servidor de Producción sobre el que se ejecutará ECC 6.0 es necesario considerar el aumento de consumo por el cambio de versión, que en este caso al tratarse de un cambio de R/3 4.7 x110 a ECC 6.0 es de un 28% aproximadamente, y se propondrá una utilización objetivo del pico medio hora del 85% y el uso de Unicode. En cuanto al tamaño de la base de datos, para la nueva versión se estima que los datos necesitarán un 35%-40% adicional respecto al tamaño actual de la Base de Datos de producción más el crecimiento anual esperado. Se recomienda el siguiente dimensionamiento de servidores: SERVIDOR 1 • Contiene el entorno de Producción y Solution Manager SERVIDOR 2 • LPAR1: Contiene los entornos de Desarrollo y Test • LPAR2: Entorno necesario para realizar la actualización técnica a la versión SAP ERP 6. • Una vez finalizada la actualización, esta partición se empleará para implementar la alta disponibilidad (XSM Cross Site Mirroring de IBM) del entorno de Producción del Servidor 1. Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 51 CAPÍTULO 6 – IMPLEMENTACIÓN ARQUITECTURA DE ALTA DISPONIBILIDAD 6.1. Introducción A lo largo de este capítulo se va a realizar una descripción detallada de la implementación de la arquitectura hardware diseñada a lo largo del proyecto. En el primer apartado se van a analizar los componentes hardware que finalmente se van a emplear en la solución final. En el siguiente apartado se muestran los listados de componentes que generan las herramientas de configuración de IBM. En el cuarto apartado se tratará la instalación física de los componentes en los armarios. En el quinto apartado se detalla la configuración de los sistemas y HMC para la puesta en marcha de todo el entorno. En el último apartado se detalla la configuración de las herramientas de alta disponibilidad una vez preparados y arrancados los sistemas. 6.2. Componentes hardware solución final En este apartado se van a describir los componentes hardware que se emplearán en la solución final de alta disponibilidad. Se utilizarán dos armarios de componentes de 42U, un armario para en entorno de producción y un segundo armario para el entorno de Desarrollo/Test. En la primera fase del proyecto los dos armarios estarán en el mismo centro de cálculo para realizar la instalación y sincronización de los datos entre los dos sistemas. Una vez finalizada esta fase, el armario de Desarrollo/Test se ubicará en el centro de cálculo de respaldo de la organización. A continuación se muestra un resumen del contenido de cada armario. Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 52 6.2.1. Armario Producción A continuación se muestra la plantilla de configuración que emplearán los técnicos para realizar la instalación de los componentes en el armario de Producción: RACK PRODUCCIÓN 42 42 41 41 40 40 39 39 38 38 37 37 36 36 35 35 34 34 33 33 32 32 31 31 30 30 29 29 28 28 27 LTO 27 26 26 25 25 24 24 23 23 22 HMC 22 21 Pantalla 21 20 20 19 19 18 18 17 Expansión IOAs 17 16 16 15 15 14 14 13 Sistema 13 12 12 11 11 10 10 9 9 8 8 7 7 6 6 5 5 4 4 3 3 2 2 1 Expansión Discos 1 Tabla 10. Plantilla de instalación del armario de Producción Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 53 En la plantilla se indican los componentes y la altura del armario en la que deben ser instalados. Los siguientes componentes se instalarán en el armario: • Sistema • Expansión de almacenamiento del sistema • Expansión de IOAs del sistema • Pantalla • HMC (Hardware Management Console) • LTO o librería de cintas (Linear Tape-Open) 6.2.2. Armario Desarrollo/Test A continuación se muestra la plantilla de configuración que emplearán los técnicos para realizar la instalación de los componentes en el armario de Desarrollo/Test: RACK PRODUCCIÓN 42 42 41 41 40 40 39 39 38 38 37 37 36 36 35 35 34 34 33 33 32 32 31 31 30 30 29 DVD-ROM Externo 29 28 28 27 LTO 27 26 26 25 25 24 24 23 23 22 HMC 22 21 Pantalla 21 20 20 19 19 18 18 17 Expansión IOAs 17 16 16 15 15 14 14 13 Sistema 13 12 12 11 11 10 10 9 9 Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 54 8 8 7 7 6 6 5 5 4 4 3 3 2 2 1 Expansión Discos 1 Tabla 11. Plantilla de instalación del armario de Desarrollo/Test En la plantilla se indican los componentes y la altura del armario en la que deben ser instalados. Los siguientes componentes se instalarán en el armario: • Sistema • Expansión de almacenamiento del sistema • Expansión de IOAs del sistema • Pantalla • HMC (Hardware Management Console) • LTO o librería de cintas (Linear Tape-Open) • DVD-ROM Externo 6.2.3. Detalle componentes Tanto el equipo de Producción como el de Desarrollo/Test son los modelos IBM Power 6 8203-E4A de 4 vías ofreciendo 5000 SAPs por servidor físico. Figura 11. IBM Power6 8203-E4A El servidor de producción y el servidor de desarrollo contarán con 32GB de memoria física, 6 discos SAS internos de 139,5 GB de 15000 rpm, múltiples tarjetas redundadas para red y múltiples tarjetas IOA (Input Output Acces) para la conectividad con unidades de expansión del sistema. Las unidades de expansión se pueden emplear para ampliar las capacidades (capacidad de almacenamiento, tarjetas de comunicaciones, memoria e incluso aumentar en número de procesadores) del sistema principal. En este caso cada sistema dispone de una unidad de expansión de disco para poder añadir más capacidad de almacenamiento y una unidad de expansión de tarjetas IOA para aumentar las capacidades de conectividad del sistema. Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 55 Cada unidad de almacenamiento externa al sistema (TotalStorage EXP24 Disk Dwr) cuenta con 12 discos de 141.12GB 15k rpm. Estas unidades van conectadas al sistema mediante buses externos de alta velocidad y disponen de controladoras con 1,5 GB de cache. En la siguiente imagen se puede observar la unidad de expansión instalada en el armario de componentes: Figura 12. Unidad TotalStorage EXP 24 instalada en el armario Cada sistema cuenta con otra expansión externa (PCI-X EXP24 Ctl-1.5GB No IOP) para aumentar el número de tarjetas IOA (tarjetas de red, tarjetas SCSI, tarjetas de fibra óptica, etc.…) disponibles. Esta expansión permite aumentar el ancho de banda de acceso a los discos externos, conectar una LTO externa, aumentar el ancho de banda de red, etc. A continuación se muestra una imagen de la unidad de expansión de tarjetas instalada en el armario de componentes: Figura 13. Expansión PCI-X EXP24 Ctl-1.5GB instalada en armario de componentes Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 56 Las nuevas tarjetas están disponibles en la parte trasera del armario de componentes: Figura 14. Parte trasera unidad de expansión de tarjetas Todos los componentes del armario disponen de fuente de alimentación redundante conectada a dos PDU (Power Distribution Unit) distintas para evitar posibles problemas con la alimentación eléctrica. Una de las PDUs está conectada a un sistema de alimentación ininterrumpido (SAI) y la otra a la red eléctrica estabilizada de la organización. Las conexiones se realizan con conectores ZTAC de 16 A: Figura 15. Cable alimentación ZTAC 16 A Los dos armarios tienen instaladas unidades para hacer copias de seguridad del sistema (LTO o biblioteca de cintas). Este modelo de biblioteca de cintas permite tener hasta 24 cintas dentro de la unidad para automatizar el proceso de copia de seguridad. La unidad del armario de producción se emplea únicamente por ese servidor. La unidad del armario de Desarrollo/Test es empleada por las dos particiones. Es necesario crear scripts para Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 57 intercambiar las unidades entre las particiones y tener en cuenta la planificación de las copias para evitar realizarlas al mismo tiempo. Figura 16. Biblioteca de cintas IBM TS3100 Los sistemas físicos instalados en cada uno de los armarios disponen de controladores HMC (Hardware Management Console) para su gestión. Una HMC es un sistema especial de IBM que se emplea para realizar diferentes tareas en los sistemas físicos. Para realizar el particionado lógico de los sistemas físicos, como por ejemplo las particiones de Desarrollo y Test en el sistema de respaldo, es obligado disponer de una HMC. También permiten el intercambio de recursos entre particiones lógicas y tareas de gestión de los servidores (abrir incidencias con IBM, apagado remoto, planificación de tareas, lazar scripts remotos, etc.). La HMC necesita un monitor para poder trabajar con ellas en el armario, aunque también es posible conectarse a ellas remotamente: Figura 17. Sistema de gestión HMC para sistemas físicos El armario de Desarrollo/Test tiene instalada una unidad externa de DVD-ROM aparte de la unidad que incorpora de serie el sistema físico. Esta unidad se asignará a una de las dos particiones lógicas (Desarrollo o Test) y la interna del sistema a la otra. Con esta unidad se consigue disponer permanentemente de una unidad de DVD-ROM en cada partición lógica y evitar el tener que cambiar manualmente la unidad del sistema físico entre particiones lógicas. 6.3. Listados herramienta de configuración de IBM Las configuraciones de los armarios, de los sistemas y del resto de componentes se realizan con una herramienta de configuración de IBM. Esta herramienta asegura la corrección y Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 64 El cable sobrante se puede recoger en los laterales del armario para mejorar el paso de aire y la organización del cableado. Figura 22. Soportes para cableado sobrante 6.5. Configuración de los sistemas y HMC Una vez instalados los sistemas en el armario y tras el cableado de estos el siguiente paso es la configuración de los parámetros básicos. El suministro de alimentación a los sistemas se debe de realizar de forma ordenada. Los primeros sistemas en recibir alimentación deben de ser los sistemas HMC (Hardware Management Console). Estos sistemas deben de estar configurados antes de arrancar los sistemas IBM Power. Tras el arranque y configuración de los sistemas HMC se pueden arrancar los sistemas IBM Power que pasarán a ser gestionados por los HMC. El resto de componentes se pueden arrancar después de configurar los sistemas principales. 6.5.1. Configuración HMC Producción y HMC Desarrollo/Test Cada armario dispone de una HMC para poder administrar todos los sistemas IBM Power en caso de caída de una de ellas. El sistema HMC desde el que se gestionará todo el entorno será el de producción y el sistema HMC de Desarrollo/Test se empleará como sistema de Backup en caso de fallo. Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 65 La configuración de los sistemas HMC se realiza mediante los asistentes gráficos de instalación. Durante el asistente se configuran los siguientes parámetros: • El idioma (existe la posibilidad de Español pero se suele emplear el Ingles por compatibilidad en algunas instalaciones, principalmente con SAP). • Fecha y hora. • Password de hscroot y root. • Creación de usuarios adicionales. • Configuración de los parámetros de red (Red privada y pública). • Configuración de los cortafuegos para cada una de las subredes. • Información de contacto para soporte remoto automático. Como se ha comentado anteriormente, durante la instalación se selecciona el idioma Ingles por compatibilidad con SAP: Figura 23. HMC pantalla de selección de idioma Respecto a la configuración de red de los sistemas HMC hay que diferenciar entre la red privada y la red pública. Una vez configurados los sistemas HMC se pueden acceder empleando su interfaz pública para realizar las posibles gestiones. La siguiente figura muestra el aspecto que tiene la pantalla de bienvenida de un sistema HMC: Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 66 Figura 24. HMC pantalla de inicio tras su puesta en marcha RED PRIVADA PARA SISTEMAS HMC La red privada de los sistemas HMC se emplea para la conexión directa con los sistemas IBM Power y para la gestión de los mismos, por este motivo se recomienda la utilización de una red de comunicaciones independiente para este tipo de comunicación. Esta red privada emplea un rango determinado de direcciones IP configurable por el usuario y arranca un servidor DHCP dedicado para los sistemas IBM Power. Por este motivo es recomendable que los sistemas IBM Power arranquen después de la configuración de los sistemas HMC ya que así se consigue que obtengan una IP por DHCP válida de los sistemas HMC. En la siguiente figura se muestran los interfaces disponibles para configurar en el sistema HMC: Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 67 Figura 25. HMC pantalla de selección interfaz de red Tras seleccionar el interfaz deseado es necesario indicar la velocidad de la conexión que se va a emplear para ese interfaz: Figura 26. HMC pantalla selección velocidad conexión En la siguiente figura se muestra la pantalla de selección del tipo de red que se va a crear. Es necesario crear una red privada para poder crear una red pública más adelante: Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 68 Figura 27. HMC pantalla selección tipo de red La siguiente figura muestra la pantalla de selección del rango de red para el servidor DHCP (en los casos en los que se requiera la su uso): Figura 28. HMC pantalla selección rango IP’s RED PÚBLICA PARA SISTEMAS HMC La red pública de los sistemas HMC se emplea para la conexión de los administradores. Empleando esta red se puede realizar la conexión al sistema HMC empleando un navegador Web o un cliente SSH. Una vez conectado el usuario puede realizar tareas de administración sobre el propio sistema HMC o sobre los servidores IBM Power gestionados. Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 69 Esta interfaz de red pública debe de ser accesible por todos los usuarios que necesiten realizar operaciones sobre los sistemas ya que será el punto de entrada para la gestión centralizada de los sistemas. En los interfaces públicos es recomendable configurar el cortafuegos para aumentar la seguridad. En la siguiente figura se muestra el botón de selección del tipo de interfaz público: Figura 29. HMC pantalla configuración de red pública Para que el botón de Open Network esté disponible es necesario haber creado una red privada previamente. En la siguiente pantalla se especifican los detalles de la configuración IP: Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 70 Figura 30. HMC pantalla configuración IP pública En la siguiente figura el asistente ofrece la opción de configurar el cortafuegos: Figura 31. HMC pantalla de activación del Cortafuegos En la siguiente figura se muestra la pantalla de configuración del cortafuegos. En este punto se puede permitir el acceso a nuevos servicios desde el exterior. Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 71 Figura 32. HMC pantalla de configuración del cortafuegos 6.5.2. Arranque de sistemas IBM Power Una vez arrancados y configurados los sistemas HMC es posible conectar y arrancar los sistemas IBM Power. Como se ha comentado anteriormente, los servidores IBM Power al arrancar intentan configurar sus puertos de red de gestión automáticamente empleando el protocolo DHCP. Tras obtener por DHCP los parámetros de configuración de los interfaces de red de gestión, aparecen en los sistemas HMC como sistemas pendientes de configuración. En este punto es necesario acceder a la pantalla de gestión de los sistemas HMC para finalizar la configuración de los sistemas. La siguiente figura muestra la pantalla de petición de contraseña para finalizar la configuración de un sistema IBM Power: Figura 33. HMC pantalla de autentificación de sistemas IBM Power Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 72 Como se puede observar en la anterior figura el nombre del sistema gestionado que se desea administrar desde el sistema HMC corresponde con el número de serie. Este proceso es necesario repetirlo para todos los sistemas IBM Power que se deseen gestionar desde los sistemas HMC. Tras añadir el sistema IBM Power para su administración es necesario arrancarlo para poder continuar realizando operaciones sobre él. En la siguiente figura se muestra la pantalla para arrancar sistemas gestionados: Figura 34. HMC pantalla para de arranque de sistema gestionado Una vez arrancados todos los sistemas IBM Power gestionados es posible continuar con la configuración de los mismos, en este caso se procederá a crear las diferentes particiones lógicas que se emplearán para albergar los sistemas operativos de Producción, Desarrollo y Test. 6.5.3. Creación de particiones lógicas Tras configurar los sistemas IBM Power para permitir su gestión desde los sistemas HMC y tras el arranque de los mismos, es posible preparar los sistemas gestionados para crea particiones sobre ellos. Las particiones lógicas permiten dividir los sistemas IBM Power físicos en sistemas lógicos e instalar sistemas operativos independientes en cada una de las particiones. El dimensionamiento de los sistemas físicos IBM Power se realizó en las fases previas del proyecto para poder albergar diferentes particiones lógicas en cada uno de ellos. Aún disponiendo de recursos suficientes, únicamente se van a realizar particiones lógicas en el sistema IBM Power de Desarrollo/Test y se emplearán todos los recursos de proceso del sistema de producción para una única partición. En la siguiente tabla se muestra como quedarán divididos los sistemas físicos: Sistema Físico Particiones CPU Memoria (GB) Producción Producción 4 32 Backup 2 16 Desarrollo/Test Desarrollo/Test 2 16 Tabla 16. Distribución de particiones en los sistemas físicos Implementación arquitectura de alta disponibilidad (HA) Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 73 La creación de particiones lógicas se realiza desde los sistemas HMC. Una partición lógica necesita unos recursos mínimos para funcionar: • Unidades de CPU • Memoria principal RAM • Memoria de almacenamiento secundario • Tarjetas de comunicaciones (Opcional) • Otros tipos de tarjetas para conectar dispositivos externos (Opcional) Las CPUs de un sistema físico se pueden dividir en fracciones de 0,1 unidades de CPU que es el mínimo de CPU que necesita una partición lógica para arrancar. En los sistemas físicos de este proyecto se pueden crear divisiones de CPU para 40 particiones ya que el sistema cuenta con cuatro CPUs. Como en el caso de la CPU, la memoria también se puede dividir en fracciones. En el caso de la memoria la cantidad mínima que se puede asignar a una partición varía en función del tipo de partición que se va a crear (Unix, Linux o i5/OS). Para dividir el almacenamiento secundario es necesario asignar tarjetas físicas que puedan acceder a la fuente de almacenamiento a cada una de las particiones que se desean crear. En este proyecto el acceso a la fuente de almacenamiento se realiza mediante tarjetas IOP (Input/Output Processor) o IOA (Input/Output Acces) que incorporan un procesador de entrada/salida para descargar al sistema en este tipo de operaciones. Cada partición tiene asignada una o varias tarjeta IOP para acceso a disco y así poder trabajar con el almacenamiento. Como en el caso de las tarjetas para acceso al almacenamiento secundario, para disponer de comunicaciones TCP/IP o de cualquier otro tipo es necesario asignar tarjetas IOP adecuadas a cada una de las particiones. Estas tarjetas de comunicaciones se asignan del sistema principal a cada una de las particiones lógicas para permitir la comunicación con el exterior. 6.5.4. Instalación de sistemas operativos Tras la creación de las particiones y de la asignación de los recursos y tarjetas necesarios, es posible continuar con la instalación de los sistemas operativos en cada una de las particiones creadas. Como se ha comentado anteriormente, en este proyecto se van a crear tres particiones: Producción (sistema de producción entero), Backup (en el sistema de Desarrollo/TEST), Desarrollo/Test (en el sistema de Desarrollo/Test también). El sistema operativo que se va a instalar en estas particiones es el i5/OS en su versión V6R1. Cada sistema físico cuenta con una unidad de lectora de DVD interna y el sistema de Desarrollo/Test cuenta con una unidad de DVD externa también. Esta configuración es necesaria si se desea disponer de una unidad de DVD física por partición en todo momento, ya que de otra forma sería necesario intercambiar la unidad de DVD interna (y Programas desarrollados para el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 80 5100 5200 STRSBS SBSD(QSNADS) 5300 MONMSG MSGID(CPF0000) 5400 5500 QSYS/STRSBS SBSD(QSPL) 5600 MONMSG MSGID(CPF0000) 5700 QSYS/RTVSYSVAL SYSVAL(QSTRPRTWTR) RTNVAR(&STRWTRS) 5800 IF COND(&STRWTRS = '0') THEN(GOTO CMDLBL(NOWTRS)) 5900 CALL PGM(QSYS/QWCSWTRS) 6000 MONMSG MSGID(CPF0000) 6100 NOWTRS: 6200 RETURN 6300 CHGVAR VAR(&CPYR) VALUE(&CPYR) 6400 ENDPGM * * * * F I N D E F U E N T E * * * * ARRCLU11    5722WDS V5R4M0 060210 LISTADO FUENTE SEU ARCHIVO FUENTE . . . . . CLUSTERSAP/QCLSRC MIEMBRO . . . . . . . . . ARRCLU11 SEQNBR*...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 ...+... 9 ...+... 0 100 200 /* Modificada la descripción de trabajos QSTRUPJD para que utilice + 300 el usuario ARRANQUE (copia de QSECOFR) en vez de QPGMR, ya que + 400 éste último no tiene permisos para los mandatos de cluster, etc. */ 500 600 /* Editar y compilar con la biblioteca CLUSTERSAP en LIBL */ 700 800 PGM 900 /* DCLF FILE(PRIM_VALUE) OPNID(PRIM_VALUE) */ 1000 /* DCLF FILE(RMTPRIMVAL) OPNID(RMTPRIMVAL) */ 1100 1200 DCL VAR(&NOM_CLU ) TYPE(*CHAR) LEN(10) 1300 DCL VAR(&NOD_PROD) TYPE(*CHAR) LEN( 7) 1400 DCL VAR(&NOD_BACK) TYPE(*CHAR) LEN( 7) 1500 DCL VAR(&SRL_PROD) TYPE(*CHAR) LEN( 8) 1600 DCL VAR(&SRL_BACK) TYPE(*CHAR) LEN( 8) 1700 DCL VAR(&DOM_ADM ) TYPE(*CHAR) LEN(10) 1800 DCL VAR(&NOM_CRG ) TYPE(*CHAR) LEN(10) 1900 DCL VAR(&IP_CLI ) TYPE(*CHAR) LEN(15) 2000 DCL VAR(&NOM_ASP ) TYPE(*CHAR) LEN(10) 2100 DCL VAR(&NUM_ASP ) TYPE(*CHAR) LEN( 4) 2200 DCL VAR(&LIB_CLU ) TYPE(*CHAR) LEN(10) 2300 DCL VAR(&LIB_XSM ) TYPE(*CHAR) LEN(10) 2400 2500 DCL VAR(&rmtsys ) TYPE(*CHAR) LEN(15) 2600 DCL VAR(&QABNORMSW) TYPE(*CHAR) LEN(1) 2700 DCL VAR(&LOCAL_PRIM) TYPE(*CHAR) LEN(7) 2800 DCL VAR(&RMT_PRIM) TYPE(*CHAR) LEN(7) 2900 DCL VAR(&SAVF) TYPE(*CHAR) LEN(10) 3000 DCL VAR(&SRLNBR) TYPE(*CHAR) LEN(8) 3100 DCL VAR(&FIN2) TYPE(*char) LEN(1) VALUE('0') 3200 DCL VAR(&ESTADOPRD) TYPE(*char) LEN(1) VALUE('0') 3300 DCL VAR(&ESTADOBCK) TYPE(*char) LEN(1) VALUE('0') 3400 DCL VAR(&COMPRD) TYPE(*CHAR) LEN(11) + 3500 VALUE('Desconocido') 3600 DCL VAR(&COMBCK) TYPE(*CHAR) LEN(11) + 3700 VALUE('Desconocido') 3800 DCL VAR(&DIRIP) TYPE(*CHAR) LEN(15) 3900 DCL VAR(&MSGDTA) TYPE(*CHAR) LEN(80) 4000 4100 RMVLIBLE LIB(CLUSTERSAP) 4200 MONMSG MSGID(CPF2104) 4300 ADDLIBLE LIB(CLUSTERSAP) 4400 4500 DATOSCLU NOM_CLU(&NOM_CLU) NOD_PROD(&NOD_PROD) + 4600 NOD_BACK(&NOD_BACK) SRL_PROD(&SRL_PROD) + 4700 SRL_BACK(&SRL_BACK) DOM_ADM(&DOM_ADM) + 4800 NOM_CRG(&NOM_CRG) IP_CLI(&IP_CLI) + 4900 NOM_ASP(&NOM_ASP) NUM_ASP(&NUM_ASP) + 5000 LIB_CLU(&LIB_CLU) LIB_XSM(&LIB_XSM) 5100 5200 RMVLIBLE LIB(&LIB_XSM) Programas desarrollados para el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 81 5300 MONMSG MSGID(CPF0000) 5400 ADDLIBLE LIB(&LIB_XSM) 5500 5600 DLYJOB DLY(30120) /* Da tiempo a que arranque TCP/IP */ 5700 5800 5900 /* Verificar comunicaciones con nodos */ 6000 6100 /* INI: Temporal hasta que se arregle el VFYPING: LMG 06/11/08 */ 6200 /* Asume que las comunicaciones son incorrectas y + 6300 /* finaliza sin completar el arranque normal */ 6400 /* CHKOBJ OBJ(CLUSTERSAP/LMG061108) OBJTYPE(*DTAARA) */ 6500 /* MONMSG MSGID(CPF9801) EXEC(DO) */ 6600 /* RCVMSG */ 6700 /* GOTO CMDLBL(LMG1) */ 6800 /* ENDDO */ 6900 /* GOTO CMDLBL(FIN2) */ 7000 /* LMG1: */ 7100 /* FIN: Temporal hasta que se arregle el VFYPING: LMG 06/11/08 */ 7200 7300 CHGVAR VAR(&RMTSYS) VALUE(&NOD_PROD) 7400 CALL PGM(VFYPING) PARM(&RMTSYS &ESTADOPRD) 7500 IF COND(&ESTADOPRD = '1') THEN(do) 7600 CHGVAR VAR(&COMPRD) VALUE('Activo') 7700 ENDDO 7800 ELSE CMD(DO) 7900 CHGVAR VAR(&FIN2) VALUE('1') 8000 ENDDO 8100 8200 CHGVAR VAR(&RMTSYS) VALUE(&NOD_BACK) 8300 CALL PGM(VFYPING) PARM(&RMTSYS &ESTADOBCK) 8400 IF COND(&ESTADOBCK = '1') THEN(DO) 8500 CHGVAR VAR(&COMBCK) VALUE('Activo') 8600 ENDDO 8700 ELSE CMD(DO) 8800 CHGVAR VAR(&FIN2) VALUE('1') 8900 ENDDO 9000 9100 IF COND(&FIN2 = '1') THEN(GOTO CMDLBL(FIN2)) 9200 9300 /* Ya que las comunicaciones estan OK continua arranque */ 9400 9500 /* Comprobación de si la última IPL fué anómala */ 9600 /* en ese caso para el arranque de cluster FIN3 */ 9700 RTVSYSVAL SYSVAL(QABNORMSW) RTNVAR(&QABNORMSW) 9800 IF COND(&QABNORMSW *EQ '1') THEN(DO) 9900 10000 GOTO CMDLBL(FIN3) /* En caso de IPL anomala no + 10100 continua el arranque */ 10200 10300 /* Como hemos puesto este salto no continua por aqui en caso de + 10400 IPL anómala, si se quita el salto si que haria esta actualizacion + 10500 de los ficheros de control PRIM_VALUE */ 10600 10700 /* Recuperación de nodo primario actual para continuar arranque */ 10800 /* El valor del nodo actual podría estar mal */ 10900 11000 RTVSYSVAL SYSVAL(QSRLNBR) RTNVAR(&SRLNBR) 11100 PRIM_VALUE FILE_OVR(PRIM_VALUE) OPER(*READ) + 11200 VALOR(&LOCAL_PRIM) 11300 PRIM_VALUE FILE_OVR(RMTPRIMVAL) OPER(*READ) + 11400 VALOR(&RMT_PRIM) 11500 11600 /* Si se ha conmutado mientras el sistema estaba caido */ 11700 /* actualizamos el valor de PRIM_VALUE desde el nodo remoto */ 11800 /* ya que el actual no es valido - No importa el nodo en que */ 11900 /* nos encontramos en este punto */ 12000 12100 IF COND(&LOCAL_PRIM *NE &RMT_PRIM) THEN(DO) 12200 PRIM_VALUE FILE_OVR(PRIM_VALUE) OPER(*WRITE) + 12300 VALOR(&RMT_PRIM) 12400 CHGVAR VAR(&LOCAL_PRIM) VALUE(&RMT_PRIM) 12500 ENDDO 12600 12700 ENDDO Programas desarrollados para el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 82 12800 CONTINUA: 12900 13000 /* Arranque de servicios de cluster desde el nodo */ 13100 /* en que me encuentro */ 13200 CALL PGM(ARRENTORNO) 13300 RETURN 13400 13500 FIN2: /* Las comunicaciones no son correctas y finaliza */ 13600 CHGVAR VAR(&MSGDTA) VALUE('Comun. con nodo' + 13700 *BCAT &NOD_PROD *BCAT &COMPRD) 13800 SNDMSG MSG(&MSGDTA) TOUSR(*SYSOPR) 13900 14000 CHGVAR VAR(&MSGDTA) VALUE('CLUSTER: Comun. con + 14100 nodo' *BCAT &NOD_BACK *BCAT &COMBCK) 14200 SNDMSG MSG(&MSGDTA) TOUSR(*SYSOPR) 14300 14400 CHGVAR VAR(&MSGDTA) VALUE('CLUSTER: Tome las + 14500 acciones necesarias y arranque el entorno') 14600 SNDMSG MSG(&MSGDTA) TOUSR(*SYSOPR) 14700 14800 CALLSUBR SUBR(SUBMSG) 14900 RETURN 15000 15100 FIN3: 15200 CHGVAR VAR(&MSGDTA) VALUE('CLUSTER: El ultimo + 15300 apagado de sistema fue anomalo. Revisar + 15400 estados de nodos y tomar + 15500 acciones........ - + 15600 Revisar estado de + 15700 sistemas - 15800 - Lineas de comunicaciones, estado de IPs (CFGTCP + 15900 op 1) - Hacer + 16000 PING entre + 16100 sistemas - 16200 - Hacer arranque de entorno con o sin + 16300 suspension + 16400 - etc...') 16500 SNDMSG MSG(&MSGDTA) TOUSR(*SYSOPR) 16600 CALLSUBR SUBR(SUBMSG) 16700 16800 RETURN 16900 17000 /* Envía mensaje de estado y de terminación */ 17100 SUBR SUBR(SUBMSG) 17200 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA(&MSGDTA) 17300 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA(&MSGDTA) + 17400 TOPGMQ(*EXT) MSGTYPE(*STATUS) 17500 ENDSUBR 17600 17700 ENDPGM * * * * F I N D E F U E N T E * * * * ARRENTORNO    5722WDS V5R4M0 060210 LISTADO FUENTE SEU ARCHIVO FUENTE . . . . . CLUSTERSAP/QCLSRC MIEMBRO . . . . . . . . . ARRENTORNO SEQNBR*...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 100 PGM 200 300 DCL VAR(&LOCAL_PRIM) TYPE(*CHAR) LEN(7) 400 DCL VAR(&SRLNBR) TYPE(*CHAR) LEN(8) 500 600 DCL VAR(&MSGDTA) TYPE(*CHAR) LEN(80) 700 800 DCL VAR(&NOM_CLU ) TYPE(*CHAR) LEN(10) 900 DCL VAR(&NOD_PROD) TYPE(*CHAR) LEN( 7) 1000 DCL VAR(&NOD_BACK) TYPE(*CHAR) LEN( 7) 1100 DCL VAR(&SRL_PROD) TYPE(*CHAR) LEN( 8) 1200 DCL VAR(&SRL_BACK) TYPE(*CHAR) LEN( 8) 1300 DCL VAR(&DOM_ADM ) TYPE(*CHAR) LEN(10) 1400 DCL VAR(&NOM_CRG ) TYPE(*CHAR) LEN(10) 1500 DCL VAR(&IP_CLI ) TYPE(*CHAR) LEN(15) 1600 DCL VAR(&NOM_ASP ) TYPE(*CHAR) LEN(10) Programas desarrollados para el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 83 1700 DCL VAR(&NUM_ASP ) TYPE(*CHAR) LEN( 4) 1800 DCL VAR(&LIB_CLU ) TYPE(*CHAR) LEN(10) 1900 DCL VAR(&LIB_XSM ) TYPE(*CHAR) LEN(10) 2000 2100 2200 DATOSCLU NOM_CLU(&NOM_CLU) NOD_PROD(&NOD_PROD) + 2300 NOD_BACK(&NOD_BACK) SRL_PROD(&SRL_PROD) + 2400 SRL_BACK(&SRL_BACK) DOM_ADM(&DOM_ADM) + 2500 NOM_CRG(&NOM_CRG) IP_CLI(&IP_CLI) + 2600 NOM_ASP(&NOM_ASP) NUM_ASP(&NUM_ASP) + 2700 LIB_CLU(&LIB_CLU) LIB_XSM(&LIB_XSM) 2800 rmvlible &LIB_XSM 2900 monmsg cpf0000 3000 addlible &LIB_XSM 3100 3200 rmvlible &LIB_CLU 3300 monmsg cpf0000 3400 addlible &LIB_CLU 3500 3600 PRIM_VALUE FILE_OVR(PRIM_VALUE) OPER(*READ) + 3700 VALOR(&LOCAL_PRIM) 3800 3900 RTVSYSVAL SYSVAL(QSRLNBR) RTNVAR(&SRLNBR) 4000 4100 /* Comprobar si se ejecuta en el nodo que actua como primario */ 4200 SELECT 4300 WHEN COND(&SRLNBR *EQ &SRL_BACK) THEN(DO) /* HIMOXSM */ 4400 IF COND(&LOCAL_PRIM *EQ &NOD_PROD) THEN(DO) 4500 GOTO CMDLBL(EXIT) 4600 enddo 4700 ENDDO 4800 WHEN COND(&SRLNBR *EQ &SRL_PROD) THEN(DO) /* HIMOPRO */ 4900 IF COND(&LOCAL_PRIM *EQ &NOD_BACK) THEN(DO) 5000 GOTO CMDLBL(EXIT) 5100 enddo 5200 ENDDO 5300 ENDSELECT 5400 5500 /* Arranque de servicios de cluster desde el nodo */ 5600 /* en que me encuentro que es el primario */ 5700 SELECT 5800 WHEN COND(&SRLNBR *EQ &SRL_BACK) THEN(DO) /* HIMOXSM */ 5900 STRCLUNOD CLUSTER(&NOM_CLU) NODE(&NOD_BACK) 6000 MONMSG CPF0000 6100 DLYJOB DLY(5) 6200 STRCLUNOD CLUSTER(&NOM_CLU) NODE(&NOD_PROD) 6300 MONMSG CPF0000 6400 ENDDO 6500 WHEN COND(&SRLNBR *EQ &SRL_PROD) THEN(DO) /* HIMOPRO */ 6600 STRCLUNOD CLUSTER(&NOM_CLU) NODE(&NOD_PROD) 6700 MONMSG CPF0000 6800 DLYJOB DLY(5) 6900 STRCLUNOD CLUSTER(&NOM_CLU) NODE(&NOD_BACK) 7000 MONMSG CPF0000 7100 ENDDO 7200 ENDSELECT 7300 7400 DLYJOB DLY(15) 7500 7600 STRCRG CLUSTER(&NOM_CLU) CRG(&NOM_CRG) 7700 MONMSG MSGID(CPF0000) 7800 STRCRG CLUSTER(&NOM_CLU) CRG(&DOM_ADM) 7900 MONMSG MSGID(CPF0000) 8000 8100 /* DLTLIB QS36F */ 8200 /* MONMSG MSGID(CPF0000) */ 8300 8400 VRYCFG CFGOBJ(&NOM_ASP) CFGTYPE(*DEV) STATUS(*ON) 8500 MONMSG MSGID(CPF0000) 8600 8700 STRTCPIFC INTNETADR(&IP_CLI) 8800 MONMSG MSGID(CPF0000) 8900 /* XRESUME IASP(&NUM_ASP) */ 9000 STRTCPSVR SERVER(*NETSVR) 9100 MONMSG MSGID(CPF0000) Programas desarrollados para el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 84 9200 9300 MD DIR('/QFileSvr.400/SAPDESA') 9400 MONMSG MSGID(CPF0000) 9500 MD DIR('/QFileSvr.400/VHIMOPRO') 9600 MONMSG MSGID(CPF0000) 9700 9800 rmvlible &LIB_CLU 9900 rmvlible &LIB_XSM 10000 10100 SETASPGRP ASPGRP(&NOM_ASP) 10200 MONMSG MSGID(CPF0000) 10300 CALL PGM(R3SYS/SAPINIT) 10400 MONMSG MSGID(CPF0000) 10500 SETASPGRP ASPGRP(*NONE) 10600 MONMSG MSGID(CPF0000) 10700 ENDCRG CLUSTER(&NOM_CLU) CRG(&NOM_CRG) 10800 MONMSG MSGID(CPF0000) 10900 11000 RETURN 11100 11200 EXIT: /* El programa se ha de ejecutar en el nodo primario */ 11300 11400 CHGVAR VAR(&MSGDTA) VALUE('Este mandato se ha de + 11500 realizar desde nodo nodo que actua como + 11600 primario, en estos momentos aparece como + 11700 primario: ' *CAT &LOCAL_PRIM) 11800 SNDMSG MSG(&MSGDTA) TOUSR(*SYSOPR) 11900 CALLSUBR SUBR(SUBMSG) 12000 RETURN 12100 12200 /* Envía mensaje de estado y de terminación */ 12300 SUBR SUBR(SUBMSG) 12400 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA(&MSGDTA) 12500 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA(&MSGDTA) + 12600 TOPGMQ(*EXT) MSGTYPE(*STATUS) 12700 ENDSUBR 12800 ENDPGM * * * * F I N D E F U E N T E * * * * SWITCH_PLN    5722WDS V5R4M0 060210 LISTADO FUENTE SEU ARCHIVO FUENTE . . . . . CLUSTERSAP/QCLSRC MIEMBRO . . . . . . . . . SWITCH_PLN SEQNBR*...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 100 PGM 200 /* DCLF FILE(CLUSTER/PRIM_VALUE) OPNID(PRIM_VALUE) */ 300 400 DCL VAR(&LOCAL_PRIM) TYPE(*CHAR) LEN(7) 500 DCL VAR(&NODPRDACT) TYPE(*CHAR) LEN(7) 600 DCL VAR(&SRLPRDACT) TYPE(*CHAR) LEN(8) 700 DCL VAR(&MSGDTA) TYPE(*CHAR) LEN(255) 800 DCL VAR(&SRLNBR ) TYPE(*CHAR) LEN(8) 900 DCL VAR(&ARRANCA) TYPE(*CHAR) LEN(1) 1000 1100 DCL VAR(&NOM_CLU ) TYPE(*CHAR) LEN(10) 1200 DCL VAR(&NOD_PROD) TYPE(*CHAR) LEN( 7) 1300 DCL VAR(&NOD_BACK) TYPE(*CHAR) LEN( 7) 1400 DCL VAR(&SRL_PROD) TYPE(*CHAR) LEN( 8) 1500 DCL VAR(&SRL_BACK) TYPE(*CHAR) LEN( 8) 1600 DCL VAR(&DOM_ADM ) TYPE(*CHAR) LEN(10) 1700 DCL VAR(&NOM_CRG ) TYPE(*CHAR) LEN(10) 1800 DCL VAR(&IP_CLI ) TYPE(*CHAR) LEN(15) 1900 DCL VAR(&NOM_ASP ) TYPE(*CHAR) LEN(10) 2000 DCL VAR(&NUM_ASP ) TYPE(*CHAR) LEN( 4) 2100 DCL VAR(&LIB_CLU ) TYPE(*CHAR) LEN(10) 2200 DCL VAR(&LIB_XSM ) TYPE(*CHAR) LEN(10) 2300 2400 2500 DATOSCLU NOM_CLU(&NOM_CLU) NOD_PROD(&NOD_PROD) + 2600 NOD_BACK(&NOD_BACK) SRL_PROD(&SRL_PROD) + 2700 SRL_BACK(&SRL_BACK) DOM_ADM(&DOM_ADM) + 2800 NOM_CRG(&NOM_CRG) IP_CLI(&IP_CLI) + 2900 NOM_ASP(&NOM_ASP) NUM_ASP(&NUM_ASP) + Programas desarrollados para el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 85 3000 LIB_CLU(&LIB_CLU) LIB_XSM(&LIB_XSM) 3100 rmvlible &LIB_XSM 3200 monmsg cpf0000 3300 addlible &LIB_XSM 3400 3500 rmvlible &LIB_CLU 3600 monmsg cpf0000 3700 addlible &LIB_CLU 3800 3900 4000 PRIM_VALUE FILE_OVR(PRIM_VALUE) OPER(*READ) + 4100 VALOR(&LOCAL_PRIM) 4200 4300 /* Comprobar que no se ejecuta en el nodo actual de producción */ 4400 CHGVAR VAR(&NODPRDACT) VALUE(&LOCAL_PRIM) 4500 NOD2SRL NOMBRE(&NODPRDACT) SRL(&SRLPRDACT) 4600 RTVSYSVAL SYSVAL(QSRLNBR) RTNVAR(&SRLNBR) 4700 IF COND(&SRLNBR *EQ &SRLPRDACT) THEN(DO) 4800 CHGVAR VAR(&MSGDTA) VALUE('Solo se debe conmutar de + 4900 nodo desde el de backup') 5000 CALLSUBR SUBR(ENVMSG) 5100 GOTO CMDLBL(ENDPGM) 5200 ENDDO 5300 5400 5500 /* Conmuta al siguiente nodo del cluster */ 5600 /* DLTLIB QS36F + 5700 MONMSG MSGID(CPF0000) */ 5800 CHGVAR VAR(&MSGDTA) VALUE('Cambiando desde el + 5900 nodo... ' *CAT &NODPRDACT) 6000 CALLSUBR SUBR(ENVMSG) 6100 STRCRG CLUSTER(&NOM_CLU) CRG(&NOM_CRG) 6200 CHGCRGPRI CLUSTER(&NOM_CLU) CRG(&NOM_CRG) 6300 ENDCRG CLUSTER(&NOM_CLU) CRG(&NOM_CRG) 6400 6500 6600 /* ACTUALIZACION DE FICHEROS DE CONTROL DE NODO PRIMARIO ACTUAL */ 6700 /* EN BACKUP Y PRODUCCIÓN. */ 6800 6900 CHGVAR VAR(&MSGDTA) VALUE('Actualizando ficheros de + 7000 control..') 7100 CALLSUBR SUBR(ENVMSG) 7200 IF COND(&LOCAL_PRIM *EQ &NOD_PROD) THEN(DO) 7300 CHGVAR VAR(&LOCAL_PRIM) VALUE(&NOD_BACK) 7400 ENDDO 7500 ELSE CMD(DO) 7600 CHGVAR VAR(&LOCAL_PRIM) VALUE(&NOD_PROD) 7700 ENDDO 7800 7900 PRIM_VALUE FILE_OVR(PRIM_VALUE) OPER(*WRITE) + 8000 VALOR(&LOCAL_PRIM) 8100 PRIM_VALUE FILE_OVR(RMTPRIMVAL) OPER(*WRITE) + 8200 VALOR(&LOCAL_PRIM) 8300 8400 /* ARRANCAR SERVICIOS ENTORNO SAP */ 8500 /* CAMBIAR VALOR DOMINIO?? */ 8600 CHGVAR VAR(&MSGDTA) VALUE('Arrancando servicios + 8700 IP...') 8800 CALLSUBR SUBR(ENVMSG) 8900 ENDTCPSVR SERVER(*NETSVR) 9000 /* CHGTCPDMN HOSTNAME('VHIMOPRO') /* REVISAR */ 9100 STRTCPSVR SERVER(*NETSVR) 9200 STRTCPIFC INTNETADR(&IP_CLI) 9300 MONMSG TCP1B12 /* YA ARRANCADO */ 9400 9500 /* Arranque del sistema para los usuarios */ 9600 CHGVAR VAR(&MSGDTA) VALUE('Arrancando entorno de + 9700 usuario......') 9800 CALLSUBR SUBR(ENVMSG) 9900 10000 10100 10200 MD DIR('/QFileSvr.400/SAPDESA') 10300 MONMSG CPFA0A0 10400 MD DIR('/QFileSvr.400/VHIMOPRO') Programas desarrollados para el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 86 10500 MONMSG CPFA0A0 10600 10700 rmvlible &lib_clu 10800 10900 SETASPGRP ASPGRP(&NOM_ASP) 11000 CALL PGM(R3SYS/SAPINIT) 11100 SETASPGRP ASPGRP(*NONE) 11200 11300 /* Envíar mensaje de borrado de SQL Packages */ 11400 CHGVAR VAR(&MSGDTA) VALUE('Tiene que hacer el + 11500 borrado de los SQL Package, iniciar + 11600 seesion con usuario PROADM y ejecutar el + 11700 mandato DLTR3PKG') 11800 CALLSUBR SUBR(ENVMSG) 11900 /* ENVIAR PANTALLAZO CON ESTA INFORMACION */ 12000 12100 ENDPGM: 12200 RETURN 12300 12400 /* Envía mensaje de estado y de terminación */ 12500 SUBR SUBR(ENVMSG) 12600 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA(&MSGDTA) 12700 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA(&MSGDTA) + 12800 TOPGMQ(*EXT) MSGTYPE(*STATUS) 12900 ENDSUBR 13000 13100 /* Envía mensaje de solicitud */ 13200 SUBR SUBR(ENVMSGINQ) 13300 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA(&MSGDTA) + 13400 TOPGMQ(*EXT) MSGTYPE(*INQ) 13500 ENDSUBR 13600 13700 ENDPGM * * * * F I N D E F U E N T E * * * * SWITCH_UNP    5722WDS V5R4M0 060210 LISTADO FUENTE SEU ARCHIVO FUENTE . . . . . CLUSTERSAP/QCLSRC MIEMBRO . . . . . . . . . SWITCH_UNP SEQNBR*...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 100 PGM 200 DCL VAR(&LOCAL_PRIM) TYPE(*CHAR) LEN(7) 300 DCL VAR(&NODPRDACT) TYPE(*CHAR) LEN(7) 400 DCL VAR(&SRLPRDACT) TYPE(*CHAR) LEN(8) 500 DCL VAR(&MSGDTA) TYPE(*CHAR) LEN(160) 600 DCL VAR(&SRLNBR ) TYPE(*CHAR) LEN(8) 700 DCL VAR(&ARRANCA) TYPE(*CHAR) LEN(1) 800 900 DCL VAR(&NOM_CLU ) TYPE(*CHAR) LEN(10) 1000 DCL VAR(&NOD_PROD) TYPE(*CHAR) LEN( 7) 1100 DCL VAR(&NOD_BACK) TYPE(*CHAR) LEN( 7) 1200 DCL VAR(&SRL_PROD) TYPE(*CHAR) LEN( 8) 1300 DCL VAR(&SRL_BACK) TYPE(*CHAR) LEN( 8) 1400 DCL VAR(&DOM_ADM ) TYPE(*CHAR) LEN(10) 1500 DCL VAR(&NOM_CRG ) TYPE(*CHAR) LEN(10) 1600 DCL VAR(&IP_CLI ) TYPE(*CHAR) LEN(15) 1700 DCL VAR(&NOM_ASP ) TYPE(*CHAR) LEN(10) 1800 DCL VAR(&NUM_ASP ) TYPE(*CHAR) LEN( 4) 1900 DCL VAR(&LIB_CLU ) TYPE(*CHAR) LEN(10) 2000 DCL VAR(&LIB_XSM ) TYPE(*CHAR) LEN(10) 2100 2200 2300 DATOSCLU NOM_CLU(&NOM_CLU) NOD_PROD(&NOD_PROD) + 2400 NOD_BACK(&NOD_BACK) SRL_PROD(&SRL_PROD) + 2500 SRL_BACK(&SRL_BACK) DOM_ADM(&DOM_ADM) + 2600 NOM_CRG(&NOM_CRG) IP_CLI(&IP_CLI) + 2700 NOM_ASP(&NOM_ASP) NUM_ASP(&NUM_ASP) + 2800 LIB_CLU(&LIB_CLU) LIB_XSM(&LIB_XSM) 2900 rmvlible &LIB_XSM 3000 monmsg cpf0000 3100 addlible &LIB_XSM 3200 3300 rmvlible &LIB_CLU Programas desarrollados para el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 87 3400 monmsg cpf0000 3500 addlible &LIB_CLU 3600 3700 PRIM_VALUE FILE_OVR(PRIM_VALUE) OPER(*READ) + 3800 VALOR(&LOCAL_PRIM) 3900 4000 /* Comprobar que no se ejecuta en el nodo actual de producción */ 4100 CHGVAR VAR(&NODPRDACT) VALUE(&LOCAL_PRIM) 4200 NOD2SRL NOMBRE(&NODPRDACT) SRL(&SRLPRDACT) 4300 RTVSYSVAL SYSVAL(QSRLNBR) RTNVAR(&SRLNBR) 4400 IF COND(&SRLNBR *EQ &SRLPRDACT) THEN(DO) 4500 CHGVAR VAR(&MSGDTA) VALUE('Solo se debe conmutar de + 4600 nodo desde el de backup') 4700 CALLSUBR SUBR(ENVMSG) 4800 GOTO CMDLBL(ENDPGM) 4900 ENDDO 5000 5100 5200 CHGCLUNODE CLUSTER(&NOM_CLU) NODE(&local_prim) + 5300 OPTION(*CHGSTS) 5400 DLYJOB DLY( 5) 5500 /* STRCRG CLUSTER(&NOM_CLU) CRG(&NOM_CRG) + 5600 DLYJOB DLY( 5) + 5700 STRCRG CLUSTER(&NOM_CLU) CRG(&DOM_ADM) + 5800 DLYJOB DLY( 5) */ 5900 6000 IF COND(&LOCAL_PRIM *EQ &NOD_PROD) THEN(CHGVAR + 6100 VAR(&LOCAL_PRIM) VALUE(&NOD_BACK)) 6200 ELSE CMD(CHGVAR VAR(&LOCAL_PRIM) VALUE(&NOD_PROD)) 6300 6400 /* LLAMADA A API PARA SUSPENDER XSM DE IASP 33 */ 6500 6600 CHGVAR VAR(&MSGDTA) VALUE('Suspendiendo XSM...') 6700 CALLSUBR SUBR(ENVMSG) 6800 STRCRG CLUSTER(&NOM_CLU) CRG(&NOM_CRG) 6801 DLYJOB DLY( 5) 6900 XSUSPEND IASP(&NUM_ASP) 7000 7100 CHGVAR VAR(&MSGDTA) VALUE('Activando IASP' *BCAT + 7200 &NOM_ASP) 7300 CALLSUBR SUBR(ENVMSG) 7400 /* DLTLIB QS36F + 7500 MONMSG MSGID(CPF0000) */ 7600 VRYCFG CFGOBJ(&NOM_ASP) CFGTYPE(*DEV) STATUS(*ON) 7700 7800 7900 8000 /* ACTUALIZACION DE FICHEROS DE CONTROL DE NODO PRIMARIO ACTUAL */ 8100 /* EN NODO FUNCION BACKUP */ 8200 8300 CHGVAR VAR(&MSGDTA) VALUE('Actualizando fichero + 8400 de control local...') 8500 CALLSUBR SUBR(ENVMSG) 8600 PRIM_VALUE FILE_OVR(PRIM_VALUE) OPER(*WRITE) + 8700 VALOR(&LOCAL_PRIM) 8800 8900 /* Arranque del sistema para los usuarios */ 9000 /* CAMBIAR VALOR DOMINIO?? */ 9100 CHGVAR VAR(&MSGDTA) VALUE('Arrancando servicios + 9200 IP...') 9300 CALLSUBR SUBR(ENVMSG) 9400 ENDTCPSVR SERVER(*NETSVR) 9500 /* CHGTCPDMN HOSTNAME('VHIMOPRO') /* REVISAR */ 9600 STRTCPSVR SERVER(*NETSVR) 9700 STRTCPIFC INTNETADR(&IP_CLI) 9800 MONMSG TCP1B12 /* YA ARRANCADO */ 9900 10000 /* Arranque del sistema para los usuarios */ 10100 CHGVAR VAR(&MSGDTA) VALUE('Arrancando entorno de + 10200 usuario......') 10300 CALLSUBR SUBR(ENVMSG) 10400 10500 10600 10700 MD DIR('/QFileSvr.400/SAPDESA') Programas desarrollados para el proyecto Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 88 10800 MONMSG CPFA0A0 10900 MD DIR('/QFileSvr.400/VHIMOPRO') 11000 MONMSG CPFA0A0 11100 11200 RMVLIBLE LIB(&LIB_CLU) 11300 RMVLIBLE LIB(&LIB_XSM) 11400 11500 SETASPGRP ASPGRP(&NOM_ASP) 11600 CALL PGM(R3SYS/SAPINIT) 11700 SETASPGRP ASPGRP(*NONE) 11800 11900 12000 12100 /* Envíar mensaje de borrado de SQL Packages */ 12200 CHGVAR VAR(&MSGDTA) VALUE('Tiene que hacer el + 12300 borrado de los SQL Package, iniciar + 12400 seesion con usuario PROADM y ejecutar el + 12500 mandato DLTR3PKG') 12600 CALLSUBR SUBR(ENVMSG) 12700 /* ENVIAR PANTALLAZO CON ESTA INFORMACION */ 12800 12900 13000 /* ARRANCAR XSM CUANDO EL SISTEMA REMOTO ESTE DE NUEVO OPERATIVO */ 13100 13200 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) + 13300 MSGDTA('ATENCION: SE DEBE ARRANCAR XSM + 13400 CUANDO EL SISTEMA SECUNDARIO VUELVA A + 13500 ESTAR OPERATIVO Y ACTUALIZAR EL FICHERO + 13600 PRIM_VALUE DE NODO SECUNDARIO') TOPGMQ(*EXT) 13700 13800 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) + 13900 MSGDTA('ATENCION: SE DEBE ARRANCAR XSM + 14000 CUANDO EL SISTEMA SECUNDARIO VUELVA A + 14100 ESTAR OPERATIVO Y ACTUALIZAR EL FICHERO + 14200 PRIM_VALUE DE NODO SECUNDARIO') + 14300 MSGTYPE(*ESCAPE) 14400 14500 DLYJOB DLY(20) 14600 14700 endpgm: 14800 RETURN 14900 15000 /* Envía mensaje de estado y de terminación */ 15100 SUBR SUBR(ENVMSG) 15200 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA(&MSGDTA) 15300 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA(&MSGDTA) + 15400 TOPGMQ(*EXT) MSGTYPE(*STATUS) 15500 ENDSUBR 15600 15700 /* Envía mensaje de solicitud */ 15800 SUBR SUBR(ENVMSGINQ) 15900 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA(&MSGDTA) + 16000 TOPGMQ(*EXT) MSGTYPE(*INQ) 16100 ENDSUBR 16200 16300 16400 ENDPGM * * * * F I N D E F U E N T E * * * * Se pueden encontrar los ficheros fuentes del resto de programas que se listan a continuación directamente en los sistemas en el archivo físico fuente QCLSRC de la biblioteca CLUSTERSAP. CRTARADAT CLLE DTAARA DATOS contiene valores Cluster DATOSCLU CLLE Devuelve datos de configuración del cluster PRIM_VALUE CLLE Accesos a PRIM_VALUE NOD2SRL CLLE Convierte nombre de nodo a número de serie SRL2NOD CLLE Convierte número de serie a nombre de nodo Comandos empleados para la gestión del Cluster Diseño e implantación de arquitectura hardware de alta disponibilidad (HA) para sistemas de planificación de recursos empresariales (ERP) 89 ANEXO B - COMANDOS EMPLEADOS PARA LA GESTIÓN DEL CLUSTER ChgCrgPri Este mandato se emplea para conmutar el CRG (base de datos – iASP VPRODUCCIÓN) al nodo de backup. Se cambia el nodo primario del cluster de manera que el primer backup pasa a ser el nodo primario y el primario backup. Este comando se emplea siempre que sea una conmutación planificada (no por contingencia) del iASP al nodo de backup. DspCluInf Este comando se emplea para visualizar información sobre el estado del cluster. Permite comprobar el estado de cada uno de los nodos del cluster desde cada uno de ellos. Los estados más comunes de un nodo son inactive, active, fail y partition. DspCrgInf Este comando se emplea para visualiza información sobre el estado del CRG. Se puede comprobar, si el CRG está arrancado, que nodo es primario dentro del dominio de recuperación y cual es nodo de backup. Visualizará también el estado del mismo: active, inactive, switchover... En este proyecto existen dos CRG: CRGP6 y un Dominio Administrativo DOMADMP6. EndCluNod Finaliza los servicios de cluster en el nodo especificado. También se pueden finalizar los servicios para todos los nodos del cluster. Es importante no finalizar el nodo primario de un CRG si el CRG está activo, o se puede producir una situación de failover. Primero es necesario finalizar el CRG y a continuación el nodo primario, o bien finalizar todos los nodos del cluster especificando el parámetro *all. ChgCluNode Cambiar estado del nodo de partition a fail. Se debe cambiar sólo tras confirmar que no se trata de un problema de comunicaciones, siempre tras haberse declarado una situación de contingencia. Para este caso se emplea el parámetro *chgsts (cambiar el estado). Este comando se utiliza también para cambiar la interface IP de un nodo del cluster. Strclunod Arranca los servicios de cluster en un nodo determinado. StrCrg Arrancar el grupo de recursos de cluster. AddCluNode Añadir nodo a un Cluster existente. ChgCrg Permite establecer el rol de cada uno de los sistemas (primary o backup) si en algún momento la información es inconsistente entre los nodos. Este comando permitiría además cambiar cualquier parámetro de la configuración de un CRG existente.