Acelere hacia las TI verdes - Una guía práctica para la migración de aplicaciones y el rehosting

Explore la metodología, buenas prácticas y lecciones aprendidas por el equipo de IBM Project Big Green durante las migraciones de aplicaciones

Esta guía ha sido desarrollada con base en experiencia de implementación para mover cargas de trabajo de aplicaciones desde un entorno distribuido, como la carga de trabajo de AIX® en hardware de RS 6000® Power® o Pseries® , carga de trabajo de Solaris en hardware de Sun o carga de trabajo de Linux® en hardware de x86 (esto es, IBM eServer® para IBM System z® principalmente los modelos IBM System z9® o z10® ).

Joydipto Banerjee, Especialista en Consultoría IT Certificado IBM, IBM

Joydipto BanerjeeJoydipto Banerjee fue contratado como Ingeniero de Migración en Jefe en IBM Project Big Green y se involucró con la migración de aplicaciones de plataformas de AIX a SUSE Linux en Sistemas Principales de System Z. Con casi tres años de experiencia en este campo, es un conocedor de la metodología y las fases de la migración de aplicaciones de IBM de punta a punta, con experiencia práctica en análisis, estimaciones y portación.



Debasis Choudhuri, Arquitecto Certificado Sénior IBM, IBM

Debasis ChoudhuriDebasis Choudhuri se especializa en la disciplina de infraestructura para consolidación y migración de servidores. Tiene una amplia experiencia con análisis de inventarios, evaluación del panorama de TI, arquitectura y dimensionamiento de la solución objetivo. Fue el arquitecto de varias consolidaciones de centros de datos y compromisos de transformación de TI. Actualmente es miembro del equipo de Arquitectura de Programa de IBM Big Green.



LK Swift, Arquitecto Certificado Sénior IBM, IBM

LK SwiftLK Swift es el Arquitecto en Jefe del programa de migración y consolidación de servidores en IBM.



29-10-2012

Introducción

Muchas grandes cuentas de desarrollo y mantenimiento de aplicaciones, pensando en migrar aplicaciones centrales y bases de datos a un nuevo entorno, no tienen claro dónde comenzar, cómo planificar e implementar la migración y cómo evitar los obstáculos en el proceso. La falta de conocimiento de las metodologías o guías estándar añade dificultad en la formación de un estimado para migrar aplicaciones rápida y efectivamente de una plataforma a otra.

Este artículo explora el altamente exitoso IBM Project Big Green en el que el objetivo fue consolidar aproximadamente 3.900 servidores internos de IBM en unos 30 entornos de System z Linux. El objetivo de este artículo es introducir el enfoque general seguido, compartir las buenas prácticas y herramientas y proporcionar los indicadores iniciales para la consolidación del servidor y el espacio de virtualización.

Aunque el artículo se enfocará en migraciones de igual a igual de una plataforma de UNIX® a otra, será igualmente útil en otros escenarios de migración. Está dirigido a Ingenieros de Migración, Arquitectos de Migración y Líderes de Ventas Técnicas y puede servir como referencia para cualquier compromiso de migración en todos los niveles de habilidad.


Visión general del proceso de migración

Primero entendamos la terminología carga de trabajo: una carga de trabajo es una aplicación o conjunto de aplicaciones ejecutándose en un Sistema Operativo (SO) en un entorno virtualizado o no virtualizado. Una carga de trabajo consiste en un SO ejecutándose en hardware, middleware ejecutándose en la capa del SO y un conjunto o un grupo similar de aplicaciones ejecutándose en el sistema de middleware. Algunos ejemplos de la carga de trabajo de la base de datos pueden ser:

  • Cargas de trabajo de DB2® u Oracle
  • Cargas de trabajo de aplicaciones web, como aplicaciones de Java™ , aplicaciones de WebSphere® , aplicaciones de Weblogic u otras
  • Cargas de trabajo frontales como imágenes estáticas o páginas
  • Cargas de trabajo de aplicaciones de capa media como WebSphere MQ, Message Broker, servicio web y más

Migrar diversas cargas de trabajo de UNIX como AIX, Solaris o x/Linux en z/Linux (o en cualquier plataforma), puede no ser un reto técnicamente. Recuerde que un compromiso como este puede volverse complejo debido a la falta de experiencia en la evaluación y la planificación adecuada. Una guía metódica, junto con un enfoque adecuadamente dividido en fases, solidifica el proceso de transformación. La Figura 1 captura las fases generales de un ciclo típico de migración:

Figura 1. Visión general de la migración
Diagram of the prgoression from discover to ap to provision, migrate and configure to test and go live

Cualquier compromiso de migración puede ser ampliamente categorizado:

  • La fase de Descubrimiento involucra el descubrimiento de su inventario de servidor y dependencias de aplicación
  • La fase de Correlación involucra la creación de la solicitud de migración y la topología de destino
  • Las fases de Suministro, Migración y Configuración involucran la compilación del entorno de destino, la implementación de la aplicación y la portación
  • La fase de Pruebas prueba las aplicaciones en el nuevo entorno después de su migración y después va en vivo.

Fases de migración detalladas:

  1. Identificación / inventario
  2. Calificación de servidor / aplicación
  3. Planificación y diseño
  4. Migración de servidor / aplicación
  5. Post producción

La Figura 2 a continuación proporciona flujo de migración mostrando sub-categorías específicas. Un compromiso típico de migración comienza con Identificación e Inventario del Servidor – un proceso que explora los servidores dentro del ámbito e identifica candidatos potenciales de migración. Esta lista de candidatos potenciales es aún más refinada en la siguiente etapa, que es Calificación de Servidor / Aplicación. Después de un detallado estudio de factibilidad, los candidatos finales de migración son elegidos y agrupados lógicamente para formar ondas. Esta lista final de servidores/aplicaciones calificados es entonces llevada a la siguiente fase, conocida como Planificación y Diseño , en la que hace la topología de destino detallada y la planificación de migración. Con el diseño detallado finalizado, ahora entra en la fase de implementación llamada Migración de Servidor / Aplicación , en la que desarrolla el entorno de destino, migra las aplicaciones y les realiza pruebas exhaustivas. Una vez que ha completado la migración, los nuevos servidores van en vivo y continúa con la fase de Post Producción , en la que desmantela los servidores antiguos.

Figura 2. Fases de migración detalladas
Diagram of the detailed migration phases shown as a flow chart of steps and substeps

Ahora profundizaremos en cada una de las fases y actividades para entender las etapas involucradas.


Identificación e inventario

Su primera etapa es identificar qué servidores migrar. También hará un inventario de los servidores y del software en cada servidor.

Identificación del servidor

En el compromiso de migración, es importante identificar el conjunto correcto de activos, por ejemplo, los servidores para la migración. La definición de un servidor dentro o fuera del ámbito de acuerdo con la gestión de carga de trabajo acordada es realizada por los Arquitectos del proyecto y la oficina del programa de transformación. Durante el proceso de verificación de inventario, una de las primeras tareas es tomar el stock de la carga de trabajo existente (si se basa en Intel, sistema principal u otra plataforma). IBM Tivoli® Application Dependency Discovery Manager (TADDM) es un producto útil para obtener un entendimiento de las dependencias entre servidores, aplicaciones, dispositivos de red, software, archivos de configuración, sistemas operativos y otros componentes de infraestructura de TI.

Es posible usar el modelo de distribución de carga de trabajo de muestra en la Tabla 1 para el criterio de selección inicial para el entorno de destino. La utilización real del servidor de origen en términos de CPU, RAM, E/S de Red y el porcentaje considerado para que un candidato sea elegido está oculta en esta representación. Sin embargo, este modelo puede ser utilizado con medidas de utilización aceptables dadas para decidir si un servidor es candidato para migración o si está fuera del ámbito.

Tabla 1. Modelo de distribución de carga de trabajo de muestra
Afinidad para :Características del servidor:Características de la plataforma:
Sistema principal
  • Puntas de CPU sostenidas más bajas y necesidades de memoria promedio
  • E/S altas o transaccionales
  • Proximidad con otros datos en el sistema principal
  • Software disponible en el sistema principal únicamente
  • Otros componentes de aplicación en el sistema principal
Intel
  • Ya virtualizado en Intel
  • Conteos pequeños de imágenes aisladas
  • Software disponible en Intel únicamente
  • Todas las necesidades de Linux no cumplidas por Linux en el sistema principal
AIX/UNIX
  • Puntas de CPU sostenidas altas en AIX/UNIX únicamente
  • Software disponible en AIX/UNIX únicamente
  • Ya virtualizado en AIX/UNIX

Calificación de servidor y aplicación

Refine aún más su lista de candidatos potenciales para migración.

Planificación de la transformación y estudio de factibilidad

  1. Defina la complejidad del servidor para estimar el esfuerzo de migración

    Una vez que un servidor o conjunto de servidores es identificado como candidato potencial para migrar hacia un entorno de destino virtualizado, la siguiente etapa importante es categorizar el servidor como simple, medio, complejo o muy complejo dependiendo de diversos parámetros de estudio del hardware y software del servidor. La Figura 3 proporciona un ejemplo del criterio de selección:

    Figura 3. Complejidad de migración basada en el tipo de servidor
    Colored boxes showing the various migration complexity models described

    Los servidores simples alojan sólo una aplicación o una pieza de una aplicación bajo una sola instancia de un SO, como un servidor de CPU de uno o dos núcleos basado en Wintel alojando una sola aplicación web ejecutándose en un entorno de WebSphere.

    Los servidores medios pueden alojar dos o tres aplicaciones separadas, pero no tener múltiples máquinas virtuales (VMs) definidas, y seguir ejecutándose bajo una instancia de un SO, como servidores que ejecutan múltiples instancias de una aplicación como WebSphere Application Server (WAS), DB2, IBM Http Server (IHS) frontal bajo el mismo SO, típicamente encontrado en entornos de desarrollo y de prueba.

    Los servidores complejos son frecuentemente servidores con múltiples CPUs que pueden tener particiones lógicas (LPARs) separadas definidas. Cada LPAR tiene su propia copia de un SO o múltiples VMs con copias separadas de un SO y alojando múltiples aplicaciones o no relacionadas compartiendo los mismos recursos del sistema (como E/S de red). Un ejemplo puede ser un System p® con múltiples LPARs ejecutando AIX, p-Linux OS u otro SO y VMs por separado y ejecutando muchas aplicaciones distintas, compartiendo las mismas E/S de red.

    Los servidores muy complejos típicamente tienen múltiples CPUs que pueden tener LPARs separadas, cada uno con su propia copia de un SO o múltiples VMs con copias separadas de un SO y que alojan múltiples aplicaciones no relacionadas que comparten algún recurso del sistema (como E/S de red) y que están agrupados en clúster con otros servidores separados mediante intercambio de carga o migración tras error de hardware o software. Algunos ejemplos pueden ser múltiples LPARs ejecutando un SO separado de base de datos de DB2 de p-Linux o AIX con clúster de HACMP.

  2. Defina la complejidad de la aplicación para estimar el esfuerzo de migración de las aplicaciones

    La definición de la complejidad del servidor puede no derivar el entendimiento completo de que el esfuerzo de migración como un servidor puede ser simple, pero el producto, la tecnología o la aplicación en ejecución pueden ser complejos. La categorización de complejidad desde la perspectiva de una aplicación es igualmente importante para entender la migración. La Figura 4 indica el rango de complejidad para aplicaciones de simple a muy complejo.

    Figura 4. Complejidad de migración basada en el tipo de aplicación
    Colored boxes depicting the varying application complexities described

    Aplicaciones simples

    • Bases de datos si incluyen:
      • Bases de datos más pequeñas
      • Migración dentro del Centro de Datos (DC)
      • Servidores con una sola implementación de instancia
      • Servidor con hasta dos propietarios de aplicación
      • Bases de datos sin código de lenguaje nativo para evitar la remediación de código
      • Aplicación con ventanas de cortes de fin de semana disponibles para ellas
    • Aplicaciones de WAS/Java si incluyen:
      • Un tamaño más pequeño de JVM o una sola implementación de JVM
      • Movimiento de WAS AS-IS, por ejemplo, WAS 6.1.x a 6.1.x, WAS 5.1 a 6.0.x, 6.1 a 7.0.x (sin cambio de API)
      • Servidor de aplicaciones con hasta dos propietarios de aplicación únicamente
      • Aplicaciones sin código de lenguaje nativo (p.ej., C/C++) en ellas para evitar la remediación de código
    • IHS si es:
      • Mayoritariamente páginas estáticas como HTML, imágenes, JavaScript con algunos scripts de CGI, módulos de Perl o llamadas directas a la base de datos y dependencia con la IP de código duro
    • Domino® si es:
      • Una aplicación auto-contenida dentro de una base de datos .NSF que no tiene interacción con orígenes de datos externos o scripts

    Las aplicaciones medias siempre se manejan caso por caso, ya que la evaluación entre simple y compleja depende del volumen, la base de usuario, la arquitectura, los productos de middleware y una combinación de todos estos. Por ejemplo, la migración de WebSphere Commerce (WCS) de WCS 6.x a 6.x sin ningún JSP personalizado o módulo personalizado es una migración media, pero en el momento en que se incrementa el volumen del JSP personalizado o de los módulos de programa y las versiones se actualizan de 5.5/5.6 a 6.x, tiende a moverse hacia compleja o muy compleja dependiendo del análisis de estimación de esfuerzo.

    • Otros ejemplos de migraciones de complejidad media incluyen:
      • Migración simple de aplicaciones de J2EE que necesitan retrabajo de código, pero es sólo un cambio de API de 1.4.2 a 1.5 (versión JRE)
      • Cambio de controlador de tipo 2 a tipo 4
      • Aplicaciones de Domino que utilizan base de datos o conexiones de Java hacia orígenes de datos externos [incluyendo el uso de Lotus Enterprise Integrator® (LEI)]
      • Aplicaciones personalizadas desarrolladas utilizando herramientas disponibles para el entorno de destino (se requiere poca portación)

    Aplicaciones complejas

    • Base de datos con bases de datos particionadas (DB2 con DPF) o de tamaño más grande (migración a través del DC). Los indicadores probables incluyen:
      • 1TB+ de almacenamiento adjunto al servidor
      • Bases de datos que necesitan soporte 365x24x7 con pequeñas ventanas de mantenimiento
      • Bases de datos que actualmente están implementando Recuperación de Desastres (DR)
      • Bases de datos de almacenamiento de datos que necesitan altos recursos de CPU/ES
      • Servidores con muchas instancias, como tres o más instancias en el recuadro
    • Aplicaciones de WAS/Java - WAS versión 4.0 o 5.0 a 6.0/6.1/7.0 (debido al cambio de arquitectura), WCS 5.5/5.6 a 6.x con mínima personalización, migración de portal con PDM o WCM sin personalización
    • IHS - una mezcla de contenido estático y dinámico, gran dependencia de fondo de aplicación con normas de regrabación complejas y llamadas de fondo complejas y muchas dependencias de script de CGI/Perl con dependencias de módulo de Perl de directorio o externo, CGIs codificados con pobres estándares de codificación (que requieren regrabación)
    • Domino® - código de aplicación de terceros o ampliadores, elementos de Domino utilizados dentro de un portal, uso de APIs de Domino de bajo nivel o APIs de SO, moviendo una aplicación de Domino de complejidad media de Windows® a Linux (o Linux en System z).

      En general, es posible considerar que una migración es compleja cuando una aplicación que se encuentra implementando DR, código de aplicación de terceros, código personalizado con miles de módulos que requieren portación, pero utilizando el mismo entorno de desarrollo, código personalizado que requiere un cambio del entorno de desarrollo (como la suite de herramientas de Visual Age para GNU)

    Muy Compleja
    • Bases de datos - bases de datos de DB2 moviéndose de AIX a zOS. Este tipo de migración requiere un gran retrabajo para el cambio del sistema de archivos, DPF con volumen de datos de más de 1TB, migración a través de bases de datos, como de ORACLE a DB2, Informix a DB2, migración para ampliador de DB2 no soportado en zLinux.
    • WebSphere - aplicación actualmente en ejecución en una versión anterior de WebSphere como WAS 3.5 o 4.0 y necesita cantidades significativas de retrabajo de código de forma que el código de aplicación puede ser desplegado en WAS 7.0, gran volumen de personalización del flujo de trabajo en WebSphere Process Server utilizando WebSphere Integration Developer (WID).

En general, una aplicación compleja puede tener un programa personalizado desarrollado en un lenguaje que no tiene soporte en distintos SOs, una regrabación de código es necesaria en un lenguaje separado, aplicaciones que requieren el uso de múltiples programas de API personalizados o aplicaciones que requieren el uso de APIs o bibliotecas específicas para el entorno actual.

Planificación de onda: migración en un grupo

En la Figura 5, el nivel real de complejidad de migración es determinado al tomar en cuenta la complejidad de la aplicación y de los servidores.

Figura 5. Mezclar la complejidad del servidor y la complejidad de la aplicación
Diagram showing how application and server complexity combine to type the migration complexity

La migración de servidor/aplicación típicamente ocurre mediante un enfoque de onda (grupo) determinado durante la planificación de la migración de servidor. Después de que identifica los servidores/aplicaciones que serán calificados en la fase de selección y asigna las migraciones en una onda con línea de tiempo proyectada de alto nivel. Después del arranque del proyecto de onda, la complejidad de servidor y aplicación derivará una línea de tiempo de migración en términos de complejidad total en la migración, asociada con los binarios/datos del hardware/servidor y la aplicación.

Este artículo no cubre otros procesos de planificación de onda como secuenciamiento de aplicación, prioridad de aplicación, cierre de año financiero o congelamiento corporativo, ya que son muy específicos para cada proyecto.

Una vez que forma una onda, el gestor de proyecto de onda prepara el plan de proyecto para el compromiso de migración. El gestor de proyecto consultará con el equipo del cliente para obtener un estimado del esfuerzo requerido para la prueba de sistema y la prueba de aceptación de usuario. Desde la perspectiva de la planificación de proyecto, las distintas fases son de la siguiente manera (como se muestra en la Tabla 2):

  1. Iniciación y Planificación de la Solución - Realiza el estudio de factibilidad y toma decisiones técnicas críticas. Finalizar el entorno de destino.
  2. Ejecución y Control - Crear un plan detallado para ejecutar y controlar la migración de cada aplicación calificada.
  3. Ir en Vivo y Cierre - Finalmente, tome el nuevo entorno en vivo y siga las actividades de cierre del proyecto.
Tabla 2. Fases de planificación de onda
Iniciación & Planificación de la SoluciónEjecución & ControlIr en Vivo & Cierre
  • Revisar y confirmar materiales. Consultar los principales activos.
  • Determinar entornos, zonas y mostrar tapones.
  • Decidir el entorno objetivo y la plataforma de operación.
  • Arquitecturas futuras o de destino.
  • Completar la planificación detallada, ejecución & control de la migración técnica de cada aplicación calificada.
  • Consultar & informar los principales activos.
  • Planear el corte y la post-implementación, cierre de actividades.
  • Consultar & informar principales activos sobre la planificación.

Planificación y diseño

Como parte de la fase de planificación y diseño, usted y el cliente resumirán el comportamiento del servidor y la aplicación para la migración. Con base en la evaluación, usted diseña una solución técnica.

Evaluación de la aplicación

La Evaluación de la Aplicación con el cliente sucede a través de un cuestionario seguido de una reunión con las partes interesadas claves y miembros del personal técnico del equipo de aplicación. Prepare un producto de trabajo de Cuestionario de Evaluación de Aplicación (AAQ) para capturar el comportamiento del servidor y el comportamiento de la aplicación de los servidores/aplicaciones dentro del ámbito a ser migrados.

Algunos atributos claves en un AAQ para captura de datos de usuario son:

Comportamiento del servidor:

  • Nombre del servidor (FQDN)
  • Clúster (sí/no)
  • Nombre de servidor de clúster
  • Entorno en ejecución (producción/transferencia/pruebas/desarrollo)
  • Ubicación del servidor (ciudad/centro de datos/entorno de alojamiento)
  • Tipo de servidor (web/de aplicaciones/de base de datos/híbrido)
  • Zona de red (interna/externa/DMZ)
  • Dirección IP de servidor
  • Fabricante de hardware
  • Tipo de modelo
  • Número de procesador
  • Información de memoria
  • Información de almacenamiento
  • Físico/virtual
  • Utilización del servidor
  • Utilización promedio
  • Utilización punta
  • Temporización punta
  • Historial de configuración del servidor

Comportamiento de la aplicación:

  • ¿Cuál es el nombre de la aplicación ejecutándose en el servidor?
  • Proporcione una breve descripción de la aplicación y su función empresarial. Incluya lo que hace y la operación general.
  • ¿Esta aplicación es un componente o parte de un grupo de aplicaciones empresariales más grande?
  • Si es así, ¿esta aplicación y las otras aplicaciones componentes del Grupo De Aplicaciones Empresariales (EAG) necesitan interbloqueo (por ejemplo, la aplicación u otras aplicaciones componentes del EAG tienen dependencias o funciones que están estrechamente unidas y deben ser tratadas como una unidad para cualquier acción del proyecto)?
  • ¿Esta aplicación fue desarrollada internamente o fue comprada de un Proveedor de Software Independiente? Elija una:
    • Personalizada / hecha en casa
    • COTS- sin modificaciones
    • COTS- modificaciones menores
    • COTS- modificaciones mayores
  • ¿Cuál es el principal proveedor de software y release o versión del software utilizado?
  • ¿Cuál es la plataforma actual en la que esta aplicación se ejecuta? (Windows, Linux, AIX, Solaris, otra)
  • ¿Es esta la plataforma preferida o se está considerando o deseando otra plataforma?
  • ¿Quién es el Focal de Cuenta, DPE (Ejecutivo de Proyecto de Entrega) o delegado asignado en todos los fines de sesión (como documentos técnicos o UAT) para esta aplicación?
  • ¿Hay alguna ilustración o documento disponible que pueda ayudar en el entendimiento general de cómo funciona la aplicación?
  • ¿Hay algún cambio, actualización o proyecto crítico importante planificado para la aplicación o sus servidores host?
  • Clasifique esta aplicación. Elija una:
    • Aplicación autónoma
    • Aplicación & base de datos
    • Infraestructura / utilidad
    • Web autónoma
    • Aplicación web & base de datos
  • ¿Esta aplicación utiliza algún servicio común (compartido)? Si es así, elabore (por ejemplo: firewall, proxies y redirecciones, autenticación, réplica de Lotus Notes® , MQ Series, autenticación web). Normalmente una aplicación de cara a la web puede indicar que hay servicios comunes involucrados.

Se necesitaría información más crítica para capturar la información de red y los detalles de la aplicación, así como su estrategia futura y crecimiento. Además, tal vez necesite cuestionarios separados para capturar detalles del software específico, como base de datos (DB2), middleware (WebSphere Application Server) y mensajería (WebSphere MQ), desplegado para una aplicación particular.

Diseño de la solución técnica

El diseño de la solución técnica es una de las fases más críticas del programa de gestión de transformación a media que la entrada para la verificación de inventario, el comportamiento de servidor y aplicación y el resultado de las reuniones se alimentan en el diseño de solución técnica.

Las actividades principales del diseño de la solución capturadas en Technical Solution Design (TSD), un producto de trabajo basado en Excel, son:

  • Resumen de alto nivel de la solución.
  • Registro de suposiciones específicas para el TSD y riesgos identificados.
  • Descripción de la solución incluyendo decisiones de arquitectura e impactos de aplicación.
  • Una tabla con toda la información del servidor de origen.
  • Una aplicación para la tabla de correlacionamiento de servidores contendrá una entrada para cada aplicación y cada servidor en el que se ejecuta. Será una relación de muchas con muchas.
  • Una tabla con toda la información del servidor de destino.
  • Una ilustración y descripción del entorno de destino.
  • Una descripción de la solución, que consiste en decisiones de arquitectura y consideraciones alternativas.
  • Suposiciones específicas y riesgos.

Ilustraciones de ciertos escenarios de decisión de arquitectura

Mientras se hace el diseño de la solución técnica, se deben tomar las decisiones claves de arquitectura respecto al entorno de destino, la plataforma de destino, la topología de destino y la compatibilidad de la aplicación con el entorno de destino. Los tres ejemplos son:

Ejemplo 1: Compatibilidad de producto en un entorno virtualizado de Linux

  • Área de asunto: Arquitectura de solución sobre la compatibilidad en la plataforma virtualizada de Linux
  • Sentencia del problema:El ámbito de la migración es desarrollar una pila de Linux que será clonada en tres entornos de cliente tales como, pero sin limitarse a:
    • Desarrollo
    • Prueba
    • Producción

    La aplicación de J2EE será desplegada en estos tres entornos uno tras otro.

  • Suposiciones: El contenedor de J2EE es WebSphere Application Server (WAS.)
  • Alternativas:
    1. Primero, crear el ambiente para Desarrollo con SO, middleware de WAS y después aplicar tecnología de clonación para crear entornos de Prueba y Producción
    2. Crear el entorno de Desarrollo con el SO, WAS Hypervisor Edition en middleware de Linux, y después aplicar tecnología de clonación para Prueba y Producción
  • Decisión: Ir con la alternativa 2.
  • Justificación: Si desarrolla el SO de Linux con WAS edición Standard o Enterprise, las referencias del nombre de host y la dirección IP del entorno actual se volverán integradas y estrechamente unidas durante la instalación. Después de compilar un nuevo clon de la imagen de Linux de desarrollo, WAS no funcionará en la nueva imagen compilada en Linux, ya que almacena un nombre de host y referencia de IP anteriores en numerosos lugares, incluyendo el nombre de célula y otras áreas en el perfil de WAS. Eliminar el perfil y crear un nuevo perfil causaría un esfuerzo adicional para la migración.

    Para evitar este problema, elija WAS edición Hypervisor en Linux, ya que no tiene una unión tan estrecha con el entorno actual. Puede ahorrarle el esfuerzo manual de grabar scripts para eliminar la dependencia.

Ejemplo 2: Factor de portabilidad del entorno de Linux

  • Área de asunto: Ejemplo de la arquitectura de solución en la selección de plataforma.
  • Sentencia del problema: Migrar los servidores de aplicaciones y de base de datos de fondo en AIX versus Linux en System z. Todos los componentes de aplicaciones y de fondo de DB2 del servidor están actualmente ejecutándose en un entorno de AIX no virtualizado. El cliente quiere mover el servidor a un entorno virtualizado, ya sea en Linux o AIX, para obtener las ventajas de la virtualización y una mejor plataforma informática desde las perspectivas de escalabilidad y costo operacional.
  • Suposición: La plataforma de virtualización de Linux y la plataforma de virtualización de AIX están disponibles. El modelo de precios de Linux es económicamente más atractivo que la virtualización de AIX.
  • Alternativas:
    1. Desarrollar todos los componentes en el servidor en AIX, virtualizados, ya que la plataforma de origen es AIX. Esto implica riesgos mínimos relacionados con la migración.
    2. Desarrollar todos los componentes en el servidor en Linux, virtualizados, ya que es económicamente benéfico para el cliente.
    3. Desarrollar una base de datos de fondo en AIX y un componentes frontal en AIX y Linux, virtualizados.
  • Decisión: Ir con la alternativa 3.
  • Justificación: El componente de DB2 es ideal para Linux en System z, ya que la arquitectura de Sistema Principal está mejor equipada para gestionar la carga de trabajo donde se espera una alta operación de E/S y el fondo de la base de datos de DB2 por naturaleza incurre en E/S más altas que el componente del servidor de aplicaciones. Sin embargo, el cliente también necesitó agrupación en clúster en el componente de DB2 de fondo, lo cual requirió mantener DB2 en AIX/pSeries ya que:
    • HACMP era una herramienta madura de agrupación en clúster comparada con la reciente Tivoli Storage Automation (TSA) y DB2 HADR en zLinux. Más aún, TSA no fue bien probada en entorno de pruebas de z.
    • La utilización sostenida de punta alta de los servidores de DB2 (más del 75%) creó una afinidad cercana con el hardware de pSeries® . El componente de WAS, el cual tuvo una carga de trabajo intensiva de CPU baja, fue considerado para Linux en System z.

Ejemplo 3: Aspecto operacional en el Centro de Datos del entorno de Linux

  • Área de asunto: Ejemplo de Arquitectura de Solución en la Selección del Centro de Datos.
  • Tema: Modelo de operación y ubicación del host. Desarrollar la infraestructura en el Centro de Datos de Poughkeepsie o en el Centro de Datos de Boulder.
  • Sentencia del problema: Migrar la carga de trabajo del servidor de un Centro de Datos de IBM actual en Southbury a un nuevo entorno de Linux de virtualización en Poughkeepsie, NY o Boulder, CO.
  • Alternativas:
    1. Poughkeepsie
    2. Boulder
  • Decisión: . Ir con la alternativa 1.
  • Justificación:
    • El requisito de capacidad de servidor (de alto nivel) y la capacidad de almacenamiento versus la disponibilidad de z9 y z10 así como la capacidad compartida en Poughkeepsie coincidieron cercanamente considerando la ruta de crecimiento futuro.
    • La proximidad cercana de Southbury y Poughkeepsie ayuda a facilitar la migración de datos.
    • La ventaja de la misma zona horaria de Southbury y Poughkeepsie minimiza la complejidad operacional.

Una nota sobre la planificación de capacidad y el dimensionamiento del servidor:

Las técnicas de gestión de capacidad son aplicadas para determinar las asignaciones óptimas o el dimensionamiento para los recursos en un nuevo entorno de servidor consolidado y para garantizar el rendimiento de cargas de trabajo anticipadas. El dimensionamiento apropiado del hardware del servidor de destino es crítico para garantizar:

  • Rendimiento
  • Crecimiento futuro
  • Relación de consolidación
  • Beneficios financieros

La Figura 6 muestra la interrelación de estos factores para planificación y dimensionamiento.

Figura 6. Factores para planificación de capacidad y dimensionamiento del servidor
Diagram shows how the different factors of capacity planning support each other

El dimensionamiento del servidor se basa en la recolección de datos realizada durante la fase de evaluación/inventario. Como un ejemplo, es posible calcular el dimensionamiento en un valor Relative Performance (rPerf) para cada servidor después de analizar su modelo de hardware actual, medida de rendimiento del CPU y número de núcleos y chips disponibles en el hardware existente. Busque los siguientes elementos críticos:

  • Fabricante del servidor
  • Modelo del servidor
  • Número de CPUs
  • Núcleos de CPU
  • Velocidad de CPU
  • Utilización de CPU
  • RAM instalado
  • RAM utilizado
  • Almacenamiento asignado y utilizado

El estimado se basa directamente en el CPU% punta de los otros servidores, ajustado para consideración de características de carga de trabajo. La precisión de un estimado de dimensionamiento de consolidación de servidor depende de la entrada proporcionada. La razón más común para estimados imprecisos son las utilizaciones de CPU% incorrectas de los servidores actuales. Cada utilización punta de CPU de servidor individual y el patrón de demanda punta a través de todos los servidores que son utilizados en el dimensionamiento son cruciales para lograr un buen estimado. Si las cargas punta son complementarias, eso es que ocurren en momentos distintos, el requisito de capacidad de servidor puede ser significativamente menor que si las puntas son concurrentes. Las variaciones en las características de carga de trabajo también son un factor importante. Las variaciones en las características de la carga de trabajo pueden resultar en un delta 4x en el resultado de dimensionamiento. Entradas incorrectas o imprecisas hacen que los resultados del dimensionamiento sean inválidos. Es muy importante verificar que las entradas utilizadas en el dimensionamiento reflejan con precisión las cargas de trabajo y las utilizaciones de CPU% de los servidores actuales.

También es importante que recolecte los datos de CPU% punta correctamente. Éstos deben representar el CPU% Promedio durante un intervalo de 15 a 30 minutos de demanda punta, y no una punta instantánea. Si el cliente tiene datos sobre la utilización de CPU% promedio para un turno de 8 horas o de un día, tal vez se necesite aplicar una relación de punta y promedio para reflejar correctamente las utilizaciones de CPU% de intervalo punta.

Los parámetros de dimensionamiento para el punto de referencia incluyen:

  • Programas de aplicación
  • Supervisores de rendimiento
  • Archivos de datos (conjuntos de datos) y bases de datos
  • Scripts (comandos de usuario) y trabajos
  • Tamaños de conjuntos en funcionamiento
  • Simulación terminal
  • Tamaño de la población de usuarios
  • Tiempo de reflexión promedio y distribución del tiempo de reflexión
  • Tasas de transacción
  • Criterio de tiempo de respuesta
  • Metodología operacional

Las buenas prácticas incluyen:

  • IBM utiliza información del cuestionario como entrada para el dimensionamiento
  • La simulación del dimensionamiento convierte los volúmenes empresariales planificados de los clientes en carga de trabajo potencial
  • Requisitos de CPU, memoria y disco para la producción potencial
  • Estimación funcional para la carga de trabajo real
  • Entender las guías de dimensionamiento, metodologías y herramientas
  • Validar/diferenciar la solicitud de dimensionamiento entre un dimensionamiento, una planificación de capacidad o un ejercicio de análisis de rendimiento y las herramientas y metodología utilizadas en cada escenario exclusivo, así como la forma en que aplica a este entorno del cliente
  • Utilizar IBM Sizing Tools, cuando es aplicable, o metodologías/herramientas de Dimensionamiento de ISVs, asegurándose de estar utilizando la herramienta de dimensionamiento de versión más actual
  • Entender cómo el microparticionamiento afecta al dimensionamiento y explicar en resultados de salidas
  • Proporcionar espacio y dimensionamiento múltiple, incluyendo una proyección de crecimiento
  • Precisión de la herramienta - se espera que sea de +/- 30%
  • Obtener un punto de datos volumétricos y asegurarse de que se ha finalizado la sesión, o de lo contrario podría desencadenar un efecto dominó y un dimensionamiento incorrecto
  • Considerar el impacto del paralelismo en el procesamiento de lotes

Referencia de herramienta de dimensionamiento:

  • Herramienta de dimensionamiento propiedad de IBM:VISIAN

    VISIAN es una herramienta interna de IBM basada en Excel que captura la configuración técnica del servidor de origen (como el número, tipo y velocidad de CPUs, memoria), la utilización de recursos del servidor de origen (%CPU, %Memoria, %NW y más) y toma en cuenta las características de la capa de virtualización, las limitaciones y la sobrecarga. Los hypervisors VMware ESX, MSVS, Virtual Iron y pSeries están soportados.

    VISIAN calcula lo siguiente:

    1. Número de servidores de destino requeridos
    2. Información sobre cada servidor de destino
      1. Número de máquinas virtuales
      2. Lista de servidores de origen para virtualizar en cada servidor de destino
      3. Utilización de CPU, memoria, red, espacio en disco y E/S de disco
    3. Espacio físico requerido (unidades de bastidor)
    4. Costo de hardware y software de virtualización
  • Herramientas de dimensionamiento populares de terceros
    1. VMware Capacity Planner

      A diferencia de otras herramientas, VMware Capacity Planner es un servicio de aplicación alojada que funciona sólo para entornos de VMware de destino. Instala un número de componentes en la red que recolecta y gestiona datos. Los datos son después enviados de vuelta a VMware para su análisis. Una desventaja significativa de esto es la no propiedad del software y el no poder usarlo para trabajo continuo. Cuando el análisis del proveedor está completo, normalmente se le presentan escenarios al cliente ofreciéndole distintas configuraciones para conseguir las metas de virtualización. El servicio de Capacity Planner está disponible en socios de canal de VMware, incluyendo consultores, proveedores de hardware, proveedores de software y otros puntos de venta.

    2. Novell PlateSpin PowerRecon

      La herramienta PowerRecon de Novell integra funciones para recolección remota de datos, análisis de carga de trabajo y comparaciones de planificación y escenarios para la consolidación del servidor. Analiza automáticamente las siguientes dimensiones de la carga de trabajo: CPU, disco, memoria y red.

    3. CiRBA

      CiRBA puede desarrollar estimaciones aproximadas para el dimensionamiento de hardware como un punto de partida al analizar CPU, memoria, ES, sobrecarga y almacenamiento.

    4. VMware Guided Consolidation

      Esta herramienta incorporada es parte de Virtual Infraestructura 3 (VI3) dirigida a entornos de TI más pequeños.

      Realiza un análisis sobre un grupo seleccionado de sistemas, da consejo sobre los mejores servidores para virtualización y puede realizar la conversión de Física a Virtual (P2V).

Topología de destino para colocación de la trama:

Otro aspecto importante de la migración, especialmente en un entorno virtualizado, es diseñar y tomar decisiones sobre la topología de destino y la distribución del invitado de Máquina Virtual (VM) en la trama correcta o en el contenedor físico correcto.

Apilado de aplicaciones y análisis de dependencia:

El ejercicio de planificación de capacidad y la consideración de dependencia deben discutirse y decidirse en la fase de diseño de la solución. Considere una variedad de factores de implementación para llegar al apilado de aplicaciones correcto. Algunos factores de implementación están señalados aquí mientras se hace la separación:

  1. Versión de pila del software - Por ejemplo, aplicaciones de WAS 6.0 versus aplicaciones de WAS 7.0. Los ciclos de vida de soporte de WAS difieren y su frecuencia de mantenimiento o release de fixpacks puede no ser la misma.
  2. Seguridad - Agrupar las aplicaciones necesarias para seguridad de datos nivel 4, autenticación de SSO versus no SSO en una trama separada para mantener una mejor separación de los deberes y el aislamiento.
  3. Rendimiento y desempeño - Aplicaciones que necesitan un SLA de respuesta más rápida, aplicaciones que requieren una huella de memoria más alta para sostener el rendimiento deseado, como JVM con un almacenamiento dinámico de 2GB podría llevar a un servidor de aplicaciones dedicado comparado con una simple aplicación que requiere un almacenamiento dinámico de JVM de 256 a 512 MB.
  4. Escalabilidad - Las aplicaciones compartidas que son escalables para actualizar, las aplicaciones que tienen planes para introducir servicios web en un release futuro, aplicaciones de recuperación de desastres que pueden suceder y otras categorías.
  5. Disponibilidad - Basada en SLAs
  6. Nivel de Recuperación de Desastres (DR) - Agrupar aplicaciones de Capa 1 y Capa 2 para diseñar una infraestructura optimizada de DR compartida.

Análisis a nivel de aplicación para colocación de trabaja en un entorno virtualizado:

La decisión de colocación de invitado de VM en un entorno virtualizado es importante desde la perspectiva de una correlación de aplicaciones, por ejemplo para esparcirse a través de las VMs para aplicaciones de SLA más alto. Es posible identificar el requisito funcional de la aplicación tal como, pero sin limitarse a, procesamiento de datos, trabajos de lote dirigidos de E/S más altas, procesamiento de transacciones de alto volumen, representación web junto con tiempos de carga punta durante un periodo trimestral o anual. En consecuencia, es posible entonces decidir colocarlos en una trama correcta para distribuir la carga de trabajo de toda la trama.

También es posible exceder el 100% de asignación de recursos, esto es la sobresuscripción, una planificación de capacidad on demand de virtualización, para atender la capacidad física real recomendada como un umbral superior. Esta decisión puede estar soportado por el hecho de que no todas las VMs se ejecutarán a máxima capacidad al mismo tiempo y, por lo tanto, la capacidad del procesador estará disponible para responder por la sobre-asignación. Por ejemplo, una imagen de Linux para tipos de carga de trabajo de servidor por lotes puede funcionar cohesivamente con otra imagen de Linux del servidor de transacciones más allá de la capacidad disponible, ya que la carga de trabajo del lote estará activa durante la noche cuando el servidor de transacciones está inactivo o semi-inactivo. La carga de trabajo general puede entonces ser bien balanceada y satisfacer la sobresuscripción.


Migración de servidor y aplicación

Finalmente está listo para trabajar en la migración del servidor y las aplicaciones.

Desarrollo del ambiente de TI

Una vez que el diseño de la solución está en su lugar, es momento de trabajar en el desarrollo del ambiente de destino. Un documento comúnmente conocido como una Hoha de Desarrollo es compilado con los detalles y especificaciones para las imágenes de destino que se pueden dar. Para este momento, el dimensionamiento del hardware de destino debe estar completo así como la lista de requisitos de usuario relacionados con IDs de usuario, sistemas de archivos y otros elementos.

El proceso de desarrollo del ambiente de TI real puede ser automatizado utilizando herramientas como IBM Tivoli Provisioning Manager (TPM) o puede ser manual. Dependiendo del enfoque adoptado, la hoja de desarrollo pude ser basada en Excel (para proceso manual) o un portal de interfaz basada en la web y de autoservicio apuntando a la herramienta de suministro automatizada (por ejemplo TPM).

Con cualquier enfoque que adopte, algunos de los detalles básicos en la Hoja de Desarrollo son:

  • Detalles del grupo de solicitud
    • Fecha de creación
    • Solicitante
  • Resumen de servidores de origen
    • Número de servidores
    • CPUs totales
    • Memoria total
  • Resumen de servidores de destino
    • Número de servidores
    • Total de CPUs deseados
    • Total de memoria deseada
    • Total de tamaño en disco local
  • Información de administración
    • Nombre de la aplicación
    • Cliente
    • Gestor de proyecto
  • Información de host y de red
    • Host
    • Ubicación de host
    • Arquitectura de host
    • Dirección IP primaria
    • Nombre de dominio totalmente calificado
  • Componentes del software
    • Sistema operativo
    • Base de datos
    • Middleware
  • Sistemas de archivos locales
    • Tipo de punto de montaje
    • Tamaño (MB)
    • Propietario
    • Grupo
    • Permiso
    • Volumen
  • Usuarios
    • Nombre
    • Primario
    • Grupo
    • Grupos secundarios

Una vez que la solicitud anterior es revisada por todas las partes interesadas, el equipo de migración la envía al equipo de desarrollo del servidor, el cual se prepara para entregar las imágenes una vez que están listas. El equipo de migración entonces comienza las actividades señaladas en el plan de migración.

Migración de aplicación pruebas de unidad

Antes de que las actividades de migración puedan comenzar, es necesario documentar todas las etapas involucradas en el proceso. Esta fase es llamada Planificación de la Migración y requiere la preparación de un Plan de Migración. El Plan de Migración es un documento muy detallado que describe todas las tareas a ser realizadas en secuencia por parte del equipo de migración. Incluye el nombre de la actividad, su propietario, las fechas de inicio y la duración esperada. Se espera que cada miembro del equipo de migración realice sus propias tareas como se menciona en el plan. Por ello, el Plan de Migración forma un excelente documento de seguimiento. Un Plan de Migración basado en hoja de cálculo típicamente tiene las siguientes secciones:

  • Página de portada: Nombre de proyecto, aprobadores de documento, historial de revisión
  • Servidores: Nombres de servidores de migración
  • Premigración: Tareas para cada software aplicable para la migración.
    • Verificar el cliente/servidor de DB2 instalado
    • Obtener una lista detallada de espacios de tabla del servidor de origen
    • Preparar la copia de seguridad de DB2 y las restauraciones
    • Crear una instancia de DB2 en el destino
    Algunas de las tareas específicas de aplicación incluidas en esta sección están realizando verificación de preparación del servidor, migrando sistemas de archivos de aplicación y directorios de inicio de los servidores de origen a los de destino.
  • Migración: Tareas relevantes para cada software. La configuración del entorno y la remediación del código (configurando los perfiles de usuario, los shells de inicio de sesión, las variables de entorno, corrigiendo rutas de código duro en los scripts de aplicación) también son realizadas en este momento. Algunos ejemplos de tareas de DB2 incluyen concluir servidores de base de datos en el entorno de origen, iniciar copias de seguridad de bases de datos off-line y restaurar bases de datos en el destino. Una vez que la aplicación está correctamente instalada y es operacional en el nuevo entorno, realice las pruebas de prueba/unidad de verificación del entorno.
  • Post-migración: Realice las tareas de limpieza. Elimine cualquier script personalizado o IDs de usuario temporales que se hayan creado durante la migración.
  • Detalles de Contacto: Liste los nombres de todas las personas involucradas en la actividad de migración, junto con sus detalles de contacto.
  • Problemas: (opcional) Documente los problemas enfrentados durante la migración o cualquier comentario relevante.

Verificación de preparación del servidor: (Aplicable para entornos de producción y que no sean de producción):

Después de entregar las imágenes de destino al equipo de migración, una serie de verificaciones es realizada en las imágenes del servidor para validar que están en conformidad con los requisitos (mencionados en la Hoja de Desarrollo). Esta etapa es conocida como la Verificación de Preparación del Servidor y consiste en comandos de UNIX para verificar los parámetros de la imagen.

Ejemplo:

  1. ¿Los grupos de volúmenes, volúmenes, sistemas de archivos y puntos de montaje han sido establecidos y configurados de acuerdo a lo especificado en la Hoja de Desarrollo?
    # lvs    o    # lvdisplay
    # vgs    o    # vgdisplay
    # cat fstab     ( para verificar los puntos de montaje )
  2. ¿Los sistemas de archivos han sido configurados correctamente de acuerdo a lo especificado en la Hoja de Desarrollo?
    #df –h  < filesystem>

Las verificaciones usuales son categorizadas como Usuarios, Sistema, Almacenamiento, Software Instalado y Cualquier Instrucción Especial. El Ingeniero de Migración realiza cada una y las aprueba o las rechaza. Si hay discrepancias importantes, las imágenes son enviadas de regreso al equipo de infraestructura para su corrección. Sólo después del fin de sesión es que comienza la Migración de Aplicación.

Tareas de premigración:

  • Para entornos que no son de producción:

    Antes de que concluya los servidores de origen y las aplicaciones, informe a los usuarios sobre el corte. Cada especialista de middleware realiza un conjunto de tareas relacionadas con la configuración de software como DB2, Lotus Domino y WebSphere MQ. En paralelo, las tareas de migración de binarios de la aplicación y sistemas de archivos del servidor de origen al de destino son iniciadas. Es aquí también donde los directorios de inicio de usuarios son copiados del entorno de origen al entorno de destino.

    Los métodos comúnmente utilizados de transferencia de archivos del origen al destino son tarring y después usando el modo ftp para copiar los archivos o usando rsync.

  • Para entornos de producción-

    En el ambiente de Producción, las tareas relacionadas con la configuración de diversos software como DB2 o Lotus Domino son realizadas como se mencionó anteriormente. En lugar de entornos de origen, los archivos y binarios de la aplicación son copiados de los servidores de desarrollo recién migrados (después de que los servidores van en vivo). Como en un entorno que no sea de producción, los directorios de inicio del usuario son copiados de los servidores de origen de producción respectivos.

Tareas de migración (Para entornos de Producción y que no sean de Producción):

Esta es la fase principal en la cual las tareas reales de migración definidas en el plan de migración son realizadas por los especialistas respectivos, en las áreas de diversos software como DB2, Lotus Domino o WebSphere MQ.

  • El Ingeniero de Migración verifica que los sistemas de archivos de la aplicación y los permisos en el entorno de destino estén configurados como en los servidores de origen. Algunas actividades claves en este momento son:
    • configurar perfiles de usuario, shells de inicio de sesión
    • configurar variables de entorno de aplicación
    • corregir rutas de código duro en los scripts de la aplicación
  • Una vez que la aplicación está instalada correctamente en el nuevo entorno, haga cualquier remediación de código de origen de la aplicación según lo determinado durante la fase del estudio de factibilidad y los resultados de las Pruebas de Unidad. Las principales razones para la remediación de código son los cambios en:
    • Sistema operativo
    • Compilador
    • Versiones de software
    • Script de shell de UNIX
  • Realice una profunda Prueba de Unidad antes de que entregue el nuevo servidor al equipo de aplicación para las Pruebas de Aceptación del Usuario.

Nota: El esfuerzo y complejidad de la remediación de código y el trabajo de portación tiene muy poca relevancia en el ambiente de Producción, ya que la mayoría del trabajo ya ha sido realizado en los servidores de Desarrollo.

Pruebas de integración de sistemas y pruebas de aceptación del usuario

Una vez que el trabajo de migración está completo, las aplicaciones instaladas y portadas al nuevo entorno son entregadas al equipo del cliente para verificar y validar. Durante esta fase, el equipo de pruebas del cliente realiza las pruebas a nivel de aplicación para verificar que la funcionalidad empresarial no se rompa y el nivel de rendimiento sea satisfactorio. El equipo del cliente puede consultar con el equipo de migración algunos problemas o para la resolución de los mismos durante estas pruebas.

Durante la fase de pruebas, el Gestor de Proyecto de Onda o el Ingeniero de Evaluación asignado tendrá un rol de coordinación, trabajando con el equipo del cliente para:

  • Recolectar el estado del progreso o defecto de las pruebas del equipo de pruebas del cliente diariamente y ayudará con el impulso de la resolución de defectos
  • Informar el estado de las pruebas a la Gestión y a la Oficina del Proyecto semanalmente
  • Ayudar con las dependencias de pruebas, los riesgos y los problemas

Sin embargo, el Gestor de Proyecto de Onda o el Ingeniero de Evaluación no ejecutarán pruebas ni validarán resultados, ya que esto es generalmente responsabilidad del equipo de pruebas de aplicación.

Corte para producción de servidores

Para entornos que no son de producción:

Con las Pruebas de Aceptación del Usuario completas, el equipo del cliente finaliza sesión en los nuevos servidores. Las tareas de post-migración involucran la eliminación de cualquier script personalizado y de archivos que hayan sido temporalmente instalados en el nuevo servidor para ayudar con la migración.

Para entornos de producción:

En el ambiente de producción, un conjunto completamente nuevo de actividades de corte ahora comienza. Esto involucra la conclusión de los servidores de producción en el entorno de origen e ir en vivo en el nuevo entorno. Durante esta transición, los usuarios son afectados, así que esta actividad es normalmente realizada durante la ventana de mantenimiento de la aplicación y principalmente durante los fines de semana para minimizar el tiempo de inactividad de la aplicación.

Un plan de corte basado en hoja de cálculo consiste en las siguientes secciones:

  • Servidores enumera los nombres de los servidores de producción a ser cortados.
  • Precorte enumera las tareas que incluyen la preparación para la conclusión de los servidores de origen, la verificación final del software instalado y los archivos de aplicación en el ambiente de producción, la copia de seguridad de base de datos en el entorno de origen y la restauración en el de destino, el envío de solicitudes de cambio de URL y otras acciones.
  • Corte enumera la secuencia de conclusión real de aplicaciones y trabajos de lote en el entorno de origen, comenzándolos en el entorno de destino, implementando solicitudes de cambio de URL/DNS, pruebas finales y notificando a los usuarios sobre la disponibilidad del nuevo sistema.
  • Post-corte enumera las actividades de corte. Las tareas se encargan de la coordinación de los cambios con el ambiente de producción ascendente/descendente, completando todas las tareas de documentación restantes y supervisando el nuevo ambiente hasta que se ha estabilizado.
  • Retrotracción atiende la eventualidad de que el nuevo entorno falle después de ir en vivo con una provisión para regresar al entorno anterior. Las etapas incluyen iniciar el proceso de restitución, iniciando el software y la aplicación en el entorno anterior, ejecutando los trabajos de lote y redirigiendo el URL/DNS para que apunte de nuevo a los sistemas anteriores.
  • Suposiciones enumera cualquier suposición relacionada con el corte, como:
    • Todos los programas, scripts y tablas están en el entorno de destino antes de los movimientos de datos
    • Sólo los datos de conclusión de la aplicación son requeridos para alcanzar la producción en el entorno de destino
    • Todas las pruebas están completas para satisfacer la reubicación en el destino
  • Detalles de contacto nombres de todas las personas involucradas en este corte, junto con sus detalles de contacto.
  • Problemas es una documentación opcional de problemas enfrentados durante el corte o cualquier comentario relevante.

Común para los entornos de producción y de no producción:

Verificación de Estado

El equipo de aplicación es responsable de realizar una verificación de estado en la aplicación para asegurarse de que todo va a buena velocidad. El equipo de infraestructura entonces realiza una verificación de estado final en las imágenes antes de ir en vivo. Esto incluye parches de seguridad, supervisión y garantizar que las copias de seguridad están en su lugar. Dependiendo de cuántas imágenes estén involucradas, esto puede tomar de dos a cuatro días, y necesita ser planificado en consecuencia. El equipo de infraestructura necesitará dar su aprobación en la reunión para ir en vivo indicando que estos elementos están completos.


Post producción

Después de que los servidores están en producción, el equipo de migración realiza dos etapas finales para proporcionar un periodo de garantía y finalizar los servidores anteriores.

Garantía de post corte

Una vez que los servidores de destino están en producción, el equipo de migración normalmente supervisa el rendimiento del nuevo entorno y está en espera para solucionar cualquier problema. Esto generalmente dura de diez días a dos semanas y es conocido como el periodo de garantía. Durante este periodo, el cliente tiene acceso a miembros del equipo de migración para cualquier aclaración o resolución de problemas. Después de que termina el periodo de garantía, el equipo del cliente es responsable de todo el mantenimiento y funcionamiento activo del servidor.

Conclusión y desmantelamiento o reutilización

Después de que los servidores de producción y de no producción se vuelven operacionales y completan un número previamente definido de días sin ningún problema principal o tiempo de inactividad, los servidores anteriores son concluidos y desmantelados o utilizados para otro propósito.


Seguimiento

Durante todo el proceso de migración, es esencial realizar el seguimiento de las fases del proyecto y el entregable de punta a punta. Por esta razón, es aconsejable tener una lista de comprobación, comúnmente conocida como una Lista de Comprobación de Panel de Instrumentos Técnico, un artefacto basado en Excel que contiene los elementos que se encuentran en la Figura 7.

Figura 7. Lista de comprobación de panel de instrumentos técnico
Color coded checklist example of the elements that need to be tracked during a migration

En la Lista de Comprobación de Panel de Instrumentos Técnico, la columna Elemento/Tarea enumera las actividades o entregables, es decir, las tareas en la migración, el corte y otros planes. También enumera los propietarios de cada tarea, las fechas de destino y completadas y el estado de terminación. Durante la fase de migración, como una buena práctica, el Ingeniero de Migración actualiza esta lista de comprobación al final de cada día de trabajo para reflejar el estado actual de cada tarea y entregable. Un esquema codificado por colores (verde, amarillo y rojo) ayuda a visualizar el estado del proyecto en cualquier momento dado.


Conclusión

Este artículo introdujo el concepto de la migración de aplicación junto con las guías para planear, preparar y finalmente implementar las actividades. Usted ahora tiene una clara idea sobre todas las fases de la migración, las principales decisiones de arquitectura requeridas, los productos de trabajo a preparar y el conocimiento para evitar algunos obstáculos en el proceso.

Recursos

Aprender

Obtener los productos y tecnologías

  • Evalúe los productos de IBM como mejor le parezca: descargue una prueba de producto, pruebe un producto online, use un producto en un entorno de nube o invierta unas cuantas horas en el Recinto de Seguridad de la SOA aprendiendo cómo implementar la Arquitectura Orientada a Servicios eficientemente.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=842920
ArticleTitle=Acelere hacia las TI verdes - Una guía práctica para la migración de aplicaciones y el rehosting
publish-date=10292012