Acelere para a TI Verde: um Guia Prático para a Migração e Re-hospedagem de Aplicativos

Explore a metodologia, as melhores práticas e as lições aprendidas pela equipe do projeto Big Green da IBM durante as migrações de aplicativos

Esse guia foi desenvolvido com base na experiência de implementação na movimentação de cargas de trabalho de aplicativos de um ambiente de trabalho distribuído, como carga de trabalho do AIX® no Power® ou pSeries®, hardware RS/6000® , carga de trabalho do Solaris em hardware Sun ou carga de trabalho do Linux® no hardware x86 (ou seja, do IBM eServer® para o IBM System z® principalmente os modelos IBM System z9® ou z10® ).

Joydipto Banerjee, IBM Certified Consulting IT Specialist , IBM  

Joydipto BanerjeeJoydipto Banerjee foi contratado como engenheiro líder de migração do projeto Big Green da IBM e envolveu-se com a migração de aplicativos de plataformas AIX para o SUSE Linux em mainframes System z. Com cerca de três anos de experiência nessa área, ele segue a metodologia de migração de aplicativos de ponta a ponta e fases, com experiência prática em análise, estimativa e transferência.


nível de autor Contribuidor do
        developerWorks

Debasis Choudhuri, IBM Certified Senior Architect, IBM

Photo of Debasis ChoudhuriDebasis Choudhuri é especializado na disciplina de infraestrutura para a consolidação e migração de servidores. Tem ampla experiência na análise de inventário, avaliação do panorama de TI, arquitetura e dimensionamento da solução alvo. Foi o arquiteto de vários trabalhos de consolidação de datacenter e transformação de TI. Atualmente, é membro da equipe de arquitetura de programas do IBM Big Green.



LK Swift, IBM Senior Certified Architect, IBM

LK Swift é o arquiteto chefe do programa de consolidação e migração de servidores da IBM.



06/Ago/2012

Introdução

Muitas contas grandes de desenvolvimento e manutenção de aplicativos que estão pensando em migrar aplicativos e bancos de dados para um novo ambiente não sabem por onde começar, como planejar e implementar a migração e como evitar as armadilhas durante o processo. A falta de conhecimento das metodologias ou diretrizes padrão aumenta a dificuldade da formação de uma estimativa da migração rápida e efetiva de aplicativos de uma plataforma para outra.

Este artigo trata do projeto Big Green da IBM, muito bem-sucedido, cujo objetivo era consolidar aproximadamente 3900 servidores internos da IBM em cerca de ambientes 30 Linux System z. O objetivo deste artigo é apresentar a abordagem geral adotada, compartilhar as melhores práticas e ferramentas e fornecer as indicações iniciais para a área de consolidação e virtualização de servidores.

Embora o artigo se concentre nas migrações de semelhante a semelhante, de uma plataforma UNIX® para outra, também será útil em outros cenários de migração. É voltado para engenheiros de migração, arquitetos de migração e líderes de equipes técnicas e pode servir de referência em qualquer trabalho de migração em todos os níveis de qualificação.


Visão geral do processo de migração

Primeiro, vamos entender a terminologia carga de trabalho: carga de trabalho designa um aplicativo ou conjunto de aplicativos que executa em um sistema operacional (OS) em um ambiente virtualizado ou não virtualizado. Uma carga de trabalho consiste em um OS executando em um hardware, um middleware executando na camada do OS e um conjunto ou grupo semelhante de aplicativos executando no sistema de middleware. Estes são alguns exemplos de carga de trabalho de banco de dados:

  • Cargas de trabalho de DB2® ou Oracle
  • carga de trabalho de aplicativos da web, como aplicativos Java™ , aplicativos WebSphere® , aplicativos Weblogic ou outros
  • Carga de trabalho de frontend como imagens ou páginas estáticas
  • Cargas de trabalho da camada intermediária, como WebSphere MQ, message broker, serviço da web, etc.

A migração de várias cargas de trabalho do UNIX, como AIX, Solaris ou x/Linux para o z/Linux (ou qualquer plataforma), pode não ser desafiadora do ponto de vista técnico. Lembre-se de que um trabalho desse tipo pode se tornar complexo devido à falta de experiência em avaliação e planejamento adequado. Uma diretriz metódica, juntamente com uma abordagem correta dividida em fases, solidifica o processo de transformação. A Figura 1 mostra as fases gerais de um ciclo de migração típico:

Figura 1. Visão geral da migração
Visão geral da migração

Qualquer trabalho de migração pode ser categorizado de forma geral:

  • A fase de Descoberta envolve a descoberta do inventário do servidor e das dependências de aplicativos
  • A fase de Mapeamento envolve a criação da solicitação de migração e da topologia de destino
  • As fases de Provisão, Migração e Configuração envolvem a criação do ambiente de destino, a implementação dos aplicativos e a transferência
  • A fase de Teste testa os aplicativos no novo ambiente depois da migração e inicia a produção.

Fases detalhadas da migração:

  1. Identificação/inventário
  2. Qualificação do servidor/dos aplicativos
  3. Planejamento e design
  4. Migração dos aplicativos/do servidor
  5. Pós-produção

A Figura 2 abaixo descreve o fluxo da migração, mostrando subcategorias específicas. Um trabalho de migração típico começa com a identificação e inventário do servidor – um processo que faz a varredura dos servidores incluídos no escopo e identifica possíveis candidatos à migração. Essa lista de possíveis candidatos é refinada ainda mais na etapa seguinte, a qualificação do servidor/dos aplicativos. Depois de um estudo de viabilidade detalhado, os candidatos finais à migração são escolhidos e agrupados logicamente para formar ondas. Em seguida, essa lista final de servidores/aplicativos qualificados passa para a próxima fase, conhecida como planejamento e design, na qual é feito o planejamento detalhado da topologia de destino e da migração. Com o design detalhado finalizado, a fase seguinte é a de implementação, chamada migração do servidor/dos aplicativos. Nela, acontecem o desenvolvimento do ambiente de destino, a migração dos aplicativos e os testes minuciosos. Concluída a migração, os novos servidores entram na produção e, na fase final de pós-produção, que vem a seguir, os servidores antigos são desatribuídos.

Figura 2. Fases detalhadas da migração
Fases detalhadas da migração

Aprofundaremos cada uma das fases e atividades para entender as etapas envolvidas.


Identificação e inventário

A primeira etapa é identificar os servidores que devem migrar. Além de inventariar os servidores e o software em cada servidor.

Identificação de servidores

No trabalho de migração, é importante identificar o conjunto correto de ativos, ou seja, servidores, para a migração. A definição dos servidores que estão dentro do escopo ou fora dele, de acordo com o gerenciamento de carga de trabalho estabelecido, é feita pelos arquitetos do projeto e o escritório do programa de transformação. Durante o processo de verificação do inventário, uma das primeiras tarefas é inventariar a carga de trabalho existente (caso seja baseada na Intel, em mainframe ou outra plataforma). O IBM Tivoli® Application Dependency Discovery Manager (TADDM) é um produto útil para entender as dependências entre servidores, aplicativos, dispositivos de rede, software, arquivos de configuração, sistemas operacionais e outros componentes da infraestrutura de TI.

É possível usar a amostra de modelo de distribuição de carga de trabalho na Tabela 1 como critério de seleção inicial para o ambiente de destino. A utilização real do servidor de origem em termos de CPU, RAM, E/S de rede e porcentagem considerada para que um candidato seja escolhido está oculta nesta representação. Entretanto, esse modelo pode ser usado com métricas de utilização determinadas que podem ser estabelecidas para decidir se um servidor é um candidato à migração ou está fora do escopo.

Tabela 1. Amostra de modelo de distribuição de carga de trabalho
Afinidade com:Características do servidor:Características da plataforma:
Mainframe
  • Picos mais baixos sustentados da CPU e necessidades médias de memória
  • E/S alta e/ou transacional
  • Proximidade com outros dados no mainframe
  • Software disponível somente no mainframe
  • Outros componentes do aplicativo no mainframe
Intel
  • Já virtualizado na Intel
  • Contagens baixas de imagens isoladas
  • Software disponível somente na Intel
  • Nem todas as necessidades do Linux são supridas pelo Linux no mainframe
AIX/UNIX
  • Picos altos sustentados da CPU somente em AIX/UNIX
  • Software disponível somente no AIX/UNIX
  • Já virtualizado no AIX/UNIX

Qualificação do servidor e dos aplicativos

Refine ainda mais a sua lista de possíveis candidatos à migração.

Planejamento e estudo de viabilidade da transformação

  1. Defina a complexidade do servidor e estime o esforço de migração

    Depois que um servidor ou um conjunto de servidores é identificado como possível candidato a migrar para um ambiente de destino virtualizado, a próxima etapa importante é categorizar o servidor como simples, médio, complexo ou muito complexo, dependendo dos vários parâmetros do estudo de hardware e software do servidor. A Figura 3 dá um exemplo dos critérios de seleção:

    Figura 3. Complexidade da migração com base no tipo de servidor
    Complexidade da migração com base no tipo de servidor

    Os servidores simples hospedam apenas um aplicativo ou parte dele sob uma única instância de um OS, como um servidor com CPU com um único núcleo ou dual-core baseado em Wintel que hospeda um único aplicativo da web executando em um ambiente WebSphere.

    Os servidores médios podem hospedar dois ou três aplicativos separados, mas não têm várias máquinas virtuais (VMs) definidas e ainda executam sob uma instância de um OS, como os servidores que executam várias instâncias de um aplicativo como o WebSphere Application Server (WAS), DB2, IBM Http Server (IHS) frontend sob o mesmo OS, normalmente encontrados em ambientes de teste e desenvolvimento.

    Os servidores complexos costumam ser servidores com várias CPUs que podem tem partições lógicas (LPARs) separadas definidas. Cada LPAR tem a sua própria cópia de um OS ou várias VMs com cópias separadas de um OS e hospedando vários aplicativos ou aplicativos não relacionados que compartilham os mesmos recursos do sistema (como a E/S de rede). Um exemplo disso pode ser um System p® com várias LPARs executando o OS AIX separado, p-Linux ou outro OS e VMs e executando muitos aplicativos diferentes, compartilhando a E/S de rede.

    Os servidores muito complexos têm várias CPUs, que podem ter LPARs separadas, cada uma com a sua própria cópia de um OS ou várias VMs com cópias separadas de um OS e que hospeda vários aplicativos não relacionados que compartilham algum recurso do sistema (como a E/S de rede) e que é armazenado em cluster com outros servidores separados por meio do compartilhamento de carga de hardware ou software ou fail-over. Exemplos: várias LPARs que executam um OS separado de p-Linux ou banco de dados DB2 hospedado em AIX com cluster de HACMP.

  2. Defina a complexidade do aplicativo para estimar o esforço de migração dos aplicativos

    A definição da complexidade do servidor pode não proporcionar todo o entendimento sobre o esforço de migração, já que um servidor pode ser simples, mas o produto, a tecnologia ou o aplicativo executando pode ser complexo. A categorização da complexidade sob o ponto de vista dos aplicativos é igualmente importante para entender a migração. A Figura 4 indica a faixa de complexidade dos aplicativos, de simples a muito complexo.

    Figura 4. Complexidade da migração com base no tipo de aplicativo
    Complexidade da migração com base no tipo de aplicativo

    Aplicativos simples

    • Banco de dados se eles incluem:
      • Bancos de dados menores
      • Migração dentro do Data Center (DC)
      • Servidores com implementação de instância única
      • Servidor com até dois proprietários de aplicativos
      • Bancos de dados sem código de linguagem nativa para evitar a correção do código
      • Aplicativos com janelas de indisponibilidade nos fins de semana disponíveis a eles
    • Aplicativos WAS/Java se eles incluem:
      • Tamanho menor da JVM ou implementação de JVM única
      • Movimentação do WAS no estado em que se encontra, por exemplo, do WAS 6.1.x para o 6.1.x, do WAS 5.1 para o 6.0.x, do 6.1 para o 7.0.x (sem mudança da API)
      • Servidor de aplicativos com até dois proprietários de aplicativos somente
      • Aplicativo sem código em linguagem nativa (por exemplo, C/C++) neles para evitar a correção do código
    • IHS se ele é:
      • Principalmente de páginas estáticas, como HTML, imagens, JavaScript com poucos scripts CGI, módulos Perl ou chamadas diretas ao banco de dados e dependência com o IP codificado permanentemente
    • Domino® se é:
      • Um aplicativo autocontido dentro de um banco de dados .NSF que não tem interação com origens de dados externas ou scripts

    Os aplicativos médios são sempre uma questão caso a caso, já que a avaliação entre o simples e o complexo depende do volume, base de usuários, arquitetura, produtos de middleware e uma combinação de todos esses fatores. Por exemplo, a migração do WebSphere Commerce (WCS) do WCS 6.x para o 6.x sem nenhum JSP ou módulo customizado é uma migração média, mas, no momento que o volume do JSP customizado ou os módulos do programa aumentam e as versões são atualizadas de 5.5/5.6 para 6.x, ela tende a se tornar complexa ou muito complexa, dependendo da análise de estimativa do esforço.

    • Estes são outros exemplos de migrações de complexidade média:
      • Uma migração simples de aplicativos J2EE que requer retrabalho do código, mas é somente uma mudança de API da 1.4.2 para a 1.5 (versão do JRE)
      • Mudança de driver do tipo 2 para o tipo 4
      • Os aplicativos Domino que usam conexões ao banco de dados ou Java a origens de dados externas [inclusive o uso do Lotus Enterprise Integrator® (LEI)]
      • Aplicativos customizados desenvolvidos usando as ferramentas disponíveis para o ambiente de destino (requer pouca transferência)

    Aplicativos complexos

    • Banco de dados com bancos de dados particionados (DB2 com DPF) ou tamanho maior (migração entre DC). Estes são os indicadores prováveis:
      • Mais de 1 TB de armazenamento conectado ao servidor
      • Bancos de dados que precisam de suporte 365x24x7 com janelas de manutenção pequenas
      • Bancos de dados que estão implementando recuperação de desastre (DR)
      • Bancos de dados de data warehouse que precisam de muitos recursos de CPU ou E/S
      • Servidores com muitas instâncias, como três instâncias ou mais na caixa
    • WAS/aplicativos Java - o WAS versão 4.0 ou 5.0 para o 6.0/6.1/7.0 (por causa da mudança de arquitetura), o WCS 5.5/5.6 para 6.x com customização mínima, migração de portal com PDM ou WCM sem customização
    • IHS - uma combinação de conteúdo estático e dinâmico, grande dependência do backend dos aplicativos com regras complexas de reescritura e chamadas complexas ao backend e muitas dependências de script CGI/Perl com diretório ou dependência de módulos Perl externos, CGIs codificados com padrões inadequados (que precisam ser reescritos)
    • Domino® - código do aplicativo ou extensores de terceiros, elementos de Domino usados dentro de um portal, uso de APIs de Domino de baixo nível ou APIs de OS, movendo um aplicativo Domino de complexidade média do Windows® para o Linux (ou Linux no System z).

      Em geral, é possível considerar que uma migração é complexa quando um aplicativo está implementando DR, código de aplicativo de terceiros, código customizado com milhares de módulos que requerem transferência, mas usa o mesmo ambiente de desenvolvimento, código customizado que requer mudança do ambiente de desenvolvimento (como mudar do Visual Age para o conjunto de ferramentas GNU)

    Bancos de dados
    • muito complexos - bancos de dados DB2 que passam do AIX para o zOS. Esse tipo de migração requer um grande retrabalho para a mudança de sistema de arquivos, DPF com volume de dados superior a 1 TB, migração entre bancos de dados — como do ORACLE para o DB2, do Informix para o DB2, migração para um extensor não suportado do DB2 no zLinux.
    • WebSphere - aplicativo executando em uma versão antiga do WebSphere, como o WAS 3.5 ou 4.0, e requer quantidades significativas de retrabalho no código para que o código do aplicativo possa ser implementado no WAS 7.0, grande volume de customização do fluxo de trabalho no WebSphere Process Server usando o WebSphere Integration Developer (WID).

Em geral, um aplicativo complexo pode ter um programa customizado desenvolvido em uma linguagem que não tem suporte em sistemas operacionais diferentes, há necessidade de reescrever o código em uma linguagem separada, os aplicativos requerem o uso de vários programas de API customizada ou aplicativos customizados que requerem o uso de APIs ou bibliotecas específicas para o ambiente atual.

Planejamento de ondas: migração em um grupo

Na Figura 5,, o nível real da complexidade da migração é determinado levando-se em conta a complexidade do aplicativo e dos servidores.

Figura 5. Combine a complexidade do servidor e dos aplicativos
Combine a complexidade do servidor e dos aplicativos

A migração de servidor/aplicativos normalmente acontece por meio de uma abordagem em onda (grupo) determinada durante o planejamento da migração de servidor. Depois de identificar os servidores/aplicativos qualificados na fase de triagem e designar migrações em uma onda com uma projeção de linha do tempo geral. Depois do início do projeto em ondas, a complexidade do servidor e dos aplicativos derivará uma linha de tempo da migração em termos de complexidade total na migração, associada aos dados/binários do hardware/servidor e dos aplicativos.

Este artigo não trata de outros processos de planejamento em onda, como sequenciamento de aplicativos, prioridade de aplicativos, final de ano financeiro ou congelamento corporativo, já que isso é muito específico para cada projeto.

Após a formação da onda, o gerente de projeto de onda prepara o plano do projeto para o trabalho de migração. O gerente de projeto consultará a equipe do cliente para obter uma estimativa do esforço necessário para o teste do sistema e o teste de aceitação pelos usuários. Do ponto de vista do planejamento do projeto, as diversas fases são as seguintes (como mostra a Tabela 2):

  1. Inicialização e planejamento da solução - realize o estudo de viabilidade e tome decisões técnicas críticas. Finalize o ambiente de destino.
  2. Execução e controle - crie um plano detalhado para executar e controlar a migração de cada aplicativo qualificado.
  3. Go-live e encerramento - finalmente, coloque o novo ambiente em produção e siga as atividades de encerramento do projeto.
Tabela 2. Fases do planejamento em onda
Inicialização & planejamento da soluçãoExecução & controleGo-live & encerramento
  • Revise e confirme os materiais. Consulte os responsáveis pelos ativos.
  • Determine ambientes, zonas e fatores impeditivos.
  • Determine o ambiente de destino e a plataforma operacional.
  • Arquiteturas futuras ou de destino.
  • Realize o planejamento detalhado, execução & controle da migração técnica de cada aplicativo qualificado.
  • Consulte os responsáveis pelos ativos & informe-os.
  • Planeje a transição, a pós-implantação e as atividades de fechamento.
  • Consulte os responsáveis pelos ativos & informe-os sobre o planejamento.

Planejamento e design

Na fase de planejamento e design, você e o cliente resumirão o comportamento do servidor e dos aplicativos para a migração. Com base na avaliação, uma solução técnica é projetada.

Avaliação de aplicativos

A avaliação dos aplicativos com o cliente acontece por meio de um questionário, seguido por uma reunião com os principais interessados e membros do grupo técnico da equipe de aplicativos. Prepare um produto do trabalho do questionário de avaliação de aplicativos (AAQ) para capturar o comportamento do servidor e o comportamento dos aplicativos dos servidores/aplicativos dentro do escopo a serem migrados.

Estes são alguns dos atributos-chave de um AAQ para capturar dados do usuário:

Comportamento do servidor:

  • Nome do servidor (FQDN)
  • Cluster (sim/não)
  • Nome do servidor de cluster
  • Ambiente em execução (produção/preparação/teste/desenvolvimento)
  • Localização do servidor (cidade/datacenter/ambiente de hospedagem)
  • Tipo de servidor (web/aplicativo/banco de dados/híbrido)
  • Zona de rede (interna/externa/DMZ)
  • Endereço IP do servidor
  • Fabricante do hardware
  • Tipo de modelo
  • Número de processadores
  • Informações sobre a memória
  • Informações sobre o armazenamento
  • Físico/virtual
  • Utilização do servidor
  • Utilização média
  • Pico de utilização
  • Pico de sincronização
  • Histórico de configuração do servidor

Comportamento dos aplicativos:

  • Qual é o nome do aplicativo que está executando no servidor?
  • Forneça uma breve descrição do aplicativo e de sua função de negócios. Inclua o que ele faz e a operação geral.
  • Este aplicativo é um componente ou uma parte de um grupo maior de aplicativos corporativos?
  • Se for, esse aplicativo e os outros aplicativos componentes do grupo de aplicativos corporativos (EAG) precisam de bloqueio (por exemplo, o aplicativo ou outros aplicativos componentes do EAG têm dependências ou funções fortemente acopladas e devem ser tratados como uma unidade em alguma ação do projeto)?
  • Esse aplicativo foi desenvolvido internamente ou comprado de prateleira, junto a um fornecedor de software independente? Escolha uma alternativa:
    • Customizado/desenvolvido internamente
    • COTS- sem modificações
    • COTS- pequenas modificações
    • COTS- grandes modificações
  • Qual é o principal fornecedor de software de aplicativo e release ou versão do software utilizado?
  • Em qual plataforma esse aplicativo executa atualmente? (Windows, Linux, AIX, Solaris, outro)
  • Essa é a plataforma preferencial ou há outra plataforma que está sendo considerada ou desejada?
  • Quem é o ponto focal da conta, o DPE (Delivery Project Executive) ou delegado designado em todas as autorizações (como documentos técnicos ou UAT) para esse aplicativo?
  • Há desenhos ou documentos disponíveis que podem auxiliar no entendimento geral do funcionamento do aplicativo?
  • Há grandes mudanças, upgrades ou projetos críticos planejados para esse aplicativo ou para os servidores host?
  • Classifique este aplicativo. Escolha uma alternativa:
    • Aplicativo independente
    • Aplicativo & banco de dados
    • Infraestrutura/utilitário
    • Independente da web
    • Aplicativo da web & banco de dados
  • Este aplicativo usa algum serviço comum (compartilhado)? Se usa, dê mais detalhes (por exemplo, firewall, proxies e redirecionamentos, autenticação, replicação do Lotus Notes® , MQ Series, autenticação da web). Geralmente, um aplicativo voltado para a web pode indicar a presença de serviços comuns.

Mais informações críticas seriam necessárias para capturar as informações de rede e os detalhes do aplicativo, bem como a sua estratégia futura e crescimento. Além disso, talvez sejam necessários questionários separados para capturar detalhes do software específico — como o banco de dados (DB2), o middleware (WebSphere Application Server) e o sistema de mensagens (WebSphere MQ) — implementado para um aplicativo específico.

Design da solução técnica

O design de solução técnica é uma das fases mais críticas do programa de gerenciamento da transformação, já que a entrada da verificação do inventário, do comportamento do servidor e do aplicativo e do resultado das reuniões com os clientes alimenta o design de solução técnica.

As principais atividades do design da capturadas no design da solução técnica (TSD), um produto do trabalho baseado em Excel são:

  • Resumo geral da solução.
  • Registro das suposições específicas para o TSD e dos riscos identificados.
  • Descrição da solução, com as decisões arquitetônicas e impactos no aplicativo.
  • Uma tabela com todas as informações do servidor de origem.
  • Uma tabela de mapeamento dos aplicativos para o servidor conterá uma entrada para cada aplicativo e cada servidor em que ele executa. Será uma relação de muitos para muitos.
  • Uma tabela com todas as informações do servidor de destino.
  • Uma ilustração e descrição do ambiente de destino.
  • Uma descrição da solução, formada por decisões arquitetônicas e considerações alternativas.
  • Suposições e riscos específicos.

Ilustrações de certos cenários de decisão arquitetônica

Durante a elaboração do design da solução técnica, é necessário tomar decisões arquitetônicas importantes em relação ao ambiente de destino, plataforma de destino, topologia de destino e compatibilidade dos aplicativos com o ambiente de destino. Os três exemplos disso são:

Exemplo 1: compatibilidade do produto em um ambiente virtualizado Linux

  • Área de assunto: arquitetura da solução referente à compatibilidade na plataforma virtualizada Linux
  • Declaração da questão ou problema:o escopo da migração é desenvolver uma pilha de Linux que será clonada em três ambientes do cliente, tais como (sem limitação):
    • Desenvolvimento
    • Teste
    • Produção

    O aplicativo J2EE será implementado nesses três ambientes, um após o outro.

  • Suposições: o contêiner J2EE é o WebSphere Application Server (WAS.)
  • Alternativas:
    1. Primeiro, desenvolver o ambiente para desenvolvimento com OS e middleware de WAS e, em seguida, aplicar a tecnologia de clonagem para criar ambientes de teste e produção
    2. Crie o ambiente de desenvolvimento com OS, WAS Hypervisor Edition em middleware de Linux e, em seguida, aplicar a clonagem aos ambientes de teste e produção
  • Decisão: adotar a alternativa 2.
  • Justificação: se desenvolver o OS Linux com WAS Standard ou Enterprise edition, as referências de nome do host e o endereço IP do ambiente atual ficarão integrados e fortemente acoplados durante a instalação. Depois de desenvolver um novo clone a partir da imagem do Linux do desenvolvimento, o WAS não funcionará na nova imagem desenvolvida em Linux, já que armazena referências antigas de nome do host e IP em vários locais, inclusive o nome da célula e outros locais no perfil do WAS. A remoção do perfil e a criação de um novo perfil gerariam mais esforço para a migração.

    Para evitar esse problema, escolha o WAS Hypervisor Edition no Linux, já que ele não está tão fortemente acoplado ao ambiente atual. Isso pode poupar o esforço manual de escrever scripts para remover a dependência.

Exemplo 2: fator de portabilidade do ambiente Linux

  • Área de assunto: exemplo de arquitetura da solução na seleção da plataforma.
  • Declaração da questão ou problema: migrar o aplicativo e os servidores de banco de dados de backend em AIX versus Linux no System z. Todos os componentes de backend do aplicativo do servidor e do DB2 estão executando em um ambiente AIX não virtualizado. O cliente quer mover o servidor para um ambiente virtualizado, no Linux ou no AIX, devido às vantagens da virtualização e à melhor plataforma de informática do ponto de vista da escalabilidade e do custo operacional.
  • Suposição: as plataformas de virtualização do Linux e do AIX estão disponíveis. O modelo de precificação do Linux é economicamente mais interessante que a virtualização do AIX.
  • Alternativas:
    1. Desenvolver todos os componentes dentro do servidor no AIX, virtualizados, já que a plataforma de origem é o AIX. Os riscos relacionados à migração são mínimos.
    2. Desenvolver todos os componentes dentro do servidor no Linux, virtualizado, já que isso beneficia o cliente em termos econômicos.
    3. Desenvolver o banco de dados de backend em AIX e o componente de frontend em AIX e Linux, virtualizado.
  • Decisão: adotar a alternativa 3.
  • Justificação: o componente DB2 é ideal para o Linux no System z, porque a arquitetura de mainframe tem mais recursos para gerenciar uma carga de trabalho na qual se espera uma alta operação de E/S, e o backend do banco de dados DB2, por natureza, incorre em mais E/S que o componente do servidor de aplicativos. Entretanto, o cliente também precisava de armazenamento em cluster no componente DB2 de backend. Para isso, era necessário manter o DB2 no AIX/pSeries porque:
    • O HACMP era uma ferramenta de armazenamento em cluster madura em comparação com o Tivoli Storage Automation (TSA) e o DB2 HADR em zLinux, desenvolvidos recentemente. Além disso, o TSA não foi testado adequadamente no ambiente de teste do z.
    • A utilização sustentada de pico alto dos servidores do DB2 (superior a 75%) gerou uma grande afinidade com o hardware do pSeries® . O componente WAS, que tinha uma carga de trabalho pouco intensa em termos de CPU, foi levado em consideração para o Linux em System z.

Exemplo 3: aspecto operacional no datacenter do ambiente Linux

  • Área de assunto: exemplo de arquitetura da solução na seleção do datacenter.
  • Tópico: modelo de operação e local de hosting. Desenvolver a infraestrutura no datacenter de Poughkeepsie ou no datacenter de Boulder.
  • Declaração da questão ou problema: migrar a carga de trabalho do servidor de um datacenter IBM localizado em Southbury para o novo ambiente Linux de virtualização em Poughkeepsie, Nova York ou Boulder, Colorado.
  • Alternativas:
    1. Poughkeepsie
    2. Boulder
  • Decisão:. adotar a alternativa 1.
  • Justificação:
    • O requisito de capacidade do servidor (alto nível) e a capacidade de armazenamento versus disponibilidade doz9 e do z10, bem como a capacidade compartilhada em Poughkeepsie, combinaram bastante, levando-se em conta o caminho para o crescimento futuro.
    • A proximidade de Southbury e Poughkeepsie facilita a migração de dados.
    • A vantagem do fuso horário igual em Southbury e Poughkeepsie minimiza a complexidade operacional.

Uma observação sobre o planejamento de capacidade e dimensionamento do servidor:

São aplicadas técnicas de gerenciamento da capacidade para determinar o dimensionamento ou as alocações ideais para os recursos em um novo ambiente de servidor consolidado e para garantir o desempenho para as cargas de trabalho previstas. O dimensionamento adequado do hardware do servidor de destino é crítico para garantir:

  • Desempenho
  • Crescimento futuro
  • Proporção de consolidação
  • Benefícios financeiros

A Figura 6 mostra a inter-relação desses fatores com o planejamento e o dimensionamento.

Figura 6. Fatores para o planejamento de capacidade e o dimensionamento do servidor
Fatores para o planejamento de capacidade e o dimensionamento do servidor

O dimensionamento do servidor se baseia na coleta de dados realizada durante a fase de avaliação/inventário. Como exemplo, é possível calcular o dimensionamento em um valor de Relative Performance (desempenho relativo, rPerf) para cada servidor depois de analisar o modelo de hardware atual, a métrica de desempenho da CPU e o número de núcleos e chips disponíveis no hardware já existente. Procure os itens críticos a seguir:

  • Fabricação do servidor
  • Modelo do servidor
  • Número de CPUs
  • Núcleos da CPU
  • Velocidade da CPU
  • Utilização da CPU
  • RAM instalada
  • RAM utilizada
  • Armazenamento alocado e usado

A estimativa se baseia diretamente na porcentagem máxima da CPU% dos outros servidores, ajustada para levar em conta as características da carga de trabalho. A precisão de uma estimativa do dimensionamento da consolidação do servidor depende das entradas fornecidas. O motivo mais comum da imprecisão nas estimativas são as utilizações incorretas da porcentagem da CPU dos servidores atuais. A utilização máxima da CPU de cada servidor individual e o padrão de demanda máxima em todos os servidores usados no dimensionamento são cruciais para uma boa estimativa. Se as cargas máximas são complementares, ou seja, ocorrem em momentos diferentes, o requisito de capacidade do servidor pode ser muito mais baixo do que seria se os picos fossem simultâneos. As variações nas características da carga de trabalho também são um fator importante. As variações nas características da carga de trabalho podem provocar um delta de 4x no resultado do dimensionamento. A entrada incorreta ou imprecisa torna os resultados do dimensionamento inválidos. É muito importante garantir que as entradas usadas no dimensionamento reflitam com exatidão as cargas de trabalho e as utilizações de porcentagem da CPU dos servidores atuais.

Também é importante coletar corretamente os dados de porcentagem máxima da CPU. Devem representar a porcentagem média da CPU durante um intervalo de 15 a 30 minutos da demanda máxima, não um pico instantâneo. Se o cliente tem dados sobre a média da porcentagem da utilização do CPU em um turno de oito horas ou um dia, pode ser necessário aplicar uma proporção entre o valor máximo e a média para refletir corretamente as utilizações máximas de porcentagem da CPU no intervalo.

Os parâmetros de dimensionamento para a referência são:

  • Programas de aplicativo
  • Monitores de desempenho
  • Arquivos (conjuntos) de dados e bancos de dados
  • Scripts (comandos de usuário) ou tarefas
  • Tamanhos do conjunto de trabalhos
  • Simulação do terminal
  • Tamanho da população de usuários
  • Tempo médio para pensar e distribuição do tempo para pensar
  • Taxas de transação
  • Critérios de tempo de resposta
  • Metodologia operacional

As melhores práticas são:

  • A IBM usa informações do questionário como entrada para o dimensionamento
  • A simulação do dimensionamento converte os volumes de negócios planejados do cliente para a possível carga de trabalho
  • Os requisitos de CPU, memória e disco para a possível produção
  • A estimativa funcional da carga de trabalho real
  • Entenda as diretrizes, metodologias e ferramentas de dimensionamento
  • Valide/diferencie a solicitação de dimensionamento entre um dimensionamento, um planejamento de capacidade ou um exercício de análise de desempenho e as ferramentas e a metodologia utilizadas em cada cenário específico, bem com sua aplicação ao ambiente do cliente
  • Use as IBM Sizing Tools quando for aplicável, ou as metodologias/ferramentas de dimensionamento de ISV, certificando-se de usar a sua versão mais atual
  • Entenda como o microparticionamento afeta o dimensionamento e explique nos resultados da saída
  • Forneça o espaço livre e o dimensionamento múltiplo, incluindo uma projeção de crescimento
  • Eficácia da ferramenta - espera-se que chegue a +/- 30%
  • Obtenha um ponto de dados volumétrico e certifique-se de que seja aprovado; do contrário, pode provocar um efeito dominó e um dimensionamento incorreto
  • Leve em conta o impacto do paralelismo no processamento em lote

Referência de ferramenta de dimensionamento:

  • Ferramenta de dimensionamento proprietária da IBM:VISIAN

    O VISIAN é uma ferramenta interna da IBM baseada em Excel que captura a configuração técnica do servidor de origem (como número, tipo e velocidade de CPUs, memória), utilização de recursos do servidor de origem (porcentagem de CPU, de memória, de NW, etc.) e leva em conta as características, limitações e sobrecarga da camada de virtualização. Há suporte para os hypervisors VMware ESX, MSVS, Virtual Iron e pSeries.

    O VISIAN calcula o seguinte:

    1. Número de servidores de destino necessários
    2. Informações sobre cada servidor de destino
      1. Número de máquinas virtuais
      2. Lista de servidores de origem a serem virtualizados em cada servidor de destino
      3. Utilização de CPU, memória, rede, espaço em disco e E/S de disco
    3. Espaço físico necessário (unidades de rack)
    4. Custo do hardware e do software de virtualização
  • Ferramentas de dimensionamento de terceiros bastante utilizadas
    1. VMware Capacity Planner

      Diferentemente de outras ferramentas, o VMware Capacity Planner é um serviço de aplicativo hospedado que só funciona com ambientes de destino VMware. Ele instala na rede vários componentes que coletam e gerenciam dados. Em seguida, os dados são enviados de volta à VMware para análise. A ausência de propriedade do software e a impossibilidade de usá-lo no trabalho contínuo são desvantagens significativas. Quando a análise do fornecedor é concluída, geralmente são apresentados para o cliente cenários que oferecem configurações diferentes para cumprir as metas da virtualização. O serviço Capacity Planner é oferecido pelos parceiros de canal da VMware, que englobam consultores, fornecedores de hardware, fornecedores de software e outros estabelecimentos.

    2. Novell PlateSpin PowerRecon

      A ferramenta PowerRecon da Novell integra funções para a coleta de dados remotos, análise da carga de trabalho e comparações de planejamento e cenário para a consolidação de servidores. Analisa automaticamente as seguintes dimensões da carga de trabalho: CPU, disco, memória e rede.

    3. CiRBA

      O CiRBA pode desenvolver estimativas de dimensionamento de hardware como um ponto de partida ao analisar a CPU, memória, E/S, sobrecarga e armazenamento.

    4. VMware Guided Consolidation

      Essa ferramenta integrada faz parte do Virtual Infrastructure 3 (VI3), voltado para ambientes de TI menores.

      Faz a análise de um grupo selecionado de sistemas, recomenda os melhores servidores para a virtualização e pode fazer a conversão do físico para o virtual (P2V).

Topologia de destino para o posicionamento de quadro:

Outro aspecto importante da migração, principalmente em um ambiente virtualizado, é projetar e decidir a topologia de destino e a distribuição do guest da máquina virtual (VM) no quadro (contêiner físico) correto.

Empilhamento de aplicativos e análise da dependência:

O exercício de planejamento da capacidade e a questão da dependência devem ser discutidos e decididos na fase de design de solução. Leve em conta uma variedade de fatores de implementação para chegar ao empilhamento de aplicativos correto. Alguns fatores de implementação são descritos aqui, enquanto se faz a separação:

  1. Versão da pilha de software, por exemplo, aplicativos WAS 6.0 versus aplicativos WAS 7.0. Os ciclos de vida de suporte do WAS são diferentes e a frequência de manutenção ou release de fix pack pode não ser igual.
  2. Segurança - agrupe os aplicativos necessários para a segurança de dados nível 4, autenticação SSO versus não SSO em um quadro separado para melhorar a separação de obrigações e o isolamento.
  3. Desempenho e rendimento - os aplicativos que precisam de um SLA de resposta mais rápida, aplicativos que precisam de mais área de cobertura da memória para sustentar o desempenho desejado, como una JVM com tamanho de heap de 2 GB, podem levar a um servidor de aplicativos dedicado, em comparação com um aplicativo simples que requer um tamanho de heap de JVM de 256 a 512 MB.
  4. Escalabilidade - aplicativos compartilhados que são escaláveis para atualizar, aplicativos que pretendem introduzir serviços da web em um release futuro, possíveis aplicativos de recuperação de desastre e outras categorias.
  5. Disponibilidade - baseada nos SLAs
  6. Nível de recuperação de desastre (DR) - agrupe os aplicativos da camada 1 e da camada 2 para projetar uma infraestrutura de DR compartilhada otimizada.

Análise no nível do aplicativo para posicionamento do quadro em um ambiente virtualizado:

A decisão do posicionamento do guest da VM em um ambiente virtualizado é importante sob o ponto de vista da correlação de aplicativos, por exemplo, difundir nas VMs para os aplicativos com SLA mais alto. É possível identificar o requisito funcional do aplicativo, sem se limitar a ele, por exemplo, processamento de dados, tarefas em lote movidas a uma E/S mais alta, processamento de transações em alto volume e renderização da web juntamente com horários de carga máxima durante o período de um trimestre ou um ano. Da mesma forma, é possível decidir colocá-los em um quadro correto para distribuir a carga de trabalho de todo o quadro.

Também é possível exceder os 100% da alocação de recursos, algo que se conhece como alocação excessiva, um planejamento de capacidade on demand de virtualização, para tratar da capacidade física real recomendada como limite superior. Essa decisão pode ser respaldada pelo fato de que nem todas as VMs executarão no nível máximo ao mesmo tempo e, portanto, a capacidade do processador estará disponível para a conta para alocação excessiva. Por exemplo, uma imagem do Linux para as cargas de trabalho do tipo lote/servidor pode funcionar de forma coesa com outra imagem do Linux do servidor de transações, além da capacidade disponível, porque a carga de trabalho dos lotes estará ativa à noite, quando o servidor de transações está inativo ou semi-inativo. Dessa forma, a carga de trabalho geral pode ser bem balanceada e cumprir a alocação excessiva.


Migração de servidores e aplicativos

Finalmente você está pronto para trabalhar na migração do servidor e dos aplicativos.

Desenvolvimento do ambiente de TI

Uma vez estabelecido o design de solução, é hora de trabalhar no desenvolvimento do ambiente de destino. Um documento geralmente conhecido como planilha de desenvolvimento é elaborado, contendo os detalhes e a especificação para o que seriam as imagens de destino. Nesse momento, o dimensionamento do hardware de destino deve ser concluído, bem como a lista dos requisitos dos usuários relacionados a IDs de usuário, sistemas de arquivos e outros itens.

O processo do desenvolvimento propriamente dito do ambiente de TI pode ser automatizado por meio de ferramentas como o IBM Tivoli Provisioning Manager (TPM) ou pode ser manual. Dependendo da abordagem adotada, a planilha de desenvolvimento pode ser baseada em Excel (para o processo manual) ou em um portal de interface de autoatendimento baseado na web que aponta para a ferramenta de fornecimento automatizado (por exemplo, o TPM).

Independentemente da abordagem adotada, estes são alguns dos detalhes básicos da planilha de desenvolvimento:

  • Detalhes do grupo de solicitação
    • Data de criação
    • Solicitante
  • Resumo dos servidores de origem
    • Número de servidores
    • Total de CPUs
    • Memória total
  • Resumo dos servidores de destino
    • Número de servidores
    • Total de CPUs desejadas
    • Total da memória desejada
    • Tamanho total do disco local
  • Informações administrativas
    • Nome do aplicativo
    • Cliente
    • Gerente de projeto
  • Informações sobre o host e a rede
    • Host
    • Localização do host
    • Arquitetura do host
    • Endereço IP primário
    • Nome completo do domínio
  • Componentes de software
    • Sistema operacional
    • Banco de dados
    • Middleware
  • Sistemas de arquivos locais
    • Tipo do ponto de montagem
    • Tamanho (MB)
    • Proprietário
    • Grupo
    • Permissão
    • Volume
  • Usuários
    • Nome
    • Grupo
    • primário
    • Grupos secundários

Após a análise da solicitação acima por todos os interessados, a equipe de migração a envia para a equipe de desenvolvimento do servidor, que se prepara para entregar as imagens quando elas estiverem prontas. Em seguida, a equipe de migração inicia as atividades descritas no plano de migração.

Migração do aplicativo e testes de unidade

Antes de Atividades as atividades da migração, é necessário documentar todas as etapas envolvidas no processo. A fase é chamada planejamento da migração e requer a preparação do plano de migração. O plano de migração é um documento muito detalhado que descreve todas as tarefas a ser realizadas na sequência pela equipe de migração. Inclui o nome da atividade, seu proprietário, datas de início e duração esperada. Espera-se que cada membro da equipe de migração realize suas próprias tarefas, da forma mencionada no plano. Sendo assim, o plano de migração é um excelente documento de rastreamento. Normalmente, um plano de migração baseado em planilha tem as seguintes seções:

  • Página de rosto: nome do projeto, aprovadores do documento, histórico de revisão
  • Servidores: nomes dos servidores migrados
  • Pré-migração: tarefas para cada software aplicável para a migração.
    • Verificar o cliente/servidor DB2 instalado
    • Obter a lista detalhada de espaços de tabela do servidor de origem
    • Preparar para o backup e as restaurações do DB2
    • Criar a instância do DB2 no destino
    Algumas das tarefas específicas do aplicativo incluídas nessa seção são: verificar a prontidão do servidor, migrar os sistemas de arquivos do aplicativo e diretórios iniciais do usuário dos servidores de origem para os de destino.
  • Migração: tarefas relevantes para cada software. A configuração do ambiente e a correção do código (configuração dos perfis de usuário, shells de login, variáveis de ambiente, correção dos caminhos codificados permanentemente nos scripts dos aplicativos) também são realizadas nesse momento. São exemplos de tarefas do DB2: encerrar os servidores de banco de dados no ambiente de origem, início dos backups de banco de dados offline e restauração do banco de dados no destino. Depois que o aplicativo estiver instalado corretamente e operacional no novo ambiente, realize os testes de verificação do ambiente/testes de unidade.
  • Pós-migração: realize as tarefas de limpeza. Remova os scripts customizados ou os IDs de usuário temporários criados durante a migração.
  • Detalhes de contato: liste os nomes de todas as pessoas envolvidas na atividade de migração, juntamente com os detalhes de contato.
  • Problemas: (opcional) documente os problemas ocorridos durante a migração ou quaisquer comentários relevantes.

Verificação da prontidão do servidor: (aplica-se aos ambientes de produção e aos outros tipos de ambiente):

Depois da entrega das imagens de destino para a equipe de migração, é realizada uma série de verificações nas imagens do servidor para validar que preenche os requisitos (mencionados na planilha de desenvolvimento). Essa etapa é conhecida como verificação de prontidão do servidor e consiste em comandos de UNIX para verificar os parâmetros da imagem.

Exemplo:

  1. Os grupos de volumes, volumes, sistemas de arquivos e pontos de montagem foram configurados e definidos de acordo com o especificado na planilha de desenvolvimento?
    # lvs    ou    # lvdisplay
    # vgs    ou    # vgdisplay
    # cat fstab     (para verificar os pontos de montagem)
  2. Os sistemas de arquivos foram configurados corretamente, de acordo com o especificado na planilha de desenvolvimento?
    #df –h  < sistema de arquivos>

As verificações usuais são categorizadas como Usuários, Sistema, Armazenamento, Software instalado e Instruções especiais. O engenheiro de migração examina cada uma delas e as aprova ou as rejeita. Se houver grandes discrepâncias, as imagens são enviadas de volta à equipe de infraestrutura para correção. A migração do aplicativo só é iniciada depois da aprovação.

Tarefas pré-migração:

  • Para os ambientes que não são de produção:

    Antes de encerrar os servidores de origem e aplicativos, informe os usuários sobre a indisponibilidade. Cada especialista de middleware realiza um conjunto de tarefas relacionadas à definição e configuração de softwares como o DB2, Lotus Domino e WebSphere MQ. Paralelamente, as tarefas de migrar os binários dos aplicativos e os sistemas de arquivos dos servidores de origem para os de destino são iniciadas. Esse também é o momento em que os diretórios iniciais do usuário são copiados do ambiente de origem para o de destino.

    Os métodos usados frequentemente para transferir arquivos da origem para o destino são a utilização de pacotes tar e, em seguida, o uso do modo ftp para copiar os arquivos, ou a utilização de rsync.

  • Para os ambientes de produção

    No ambiente de produção, as tarefas relacionadas com a definição e configuração de vários tipos de software, como o DB2 ou o Lotus Domino, são realizadas conforme o mencionado anteriormente. Em vez dos ambientes de origem, os arquivos de aplicativo e binários são copiados dos servidores de desenvolvimento recém-migrados (após os servidores entrarem na produção). Assim como nos ambientes que não são de produção, os diretórios iniciais do usuário são copiados dos respectivos servidores de origem da produção.

Tarefas de migração ( para ambientes de produção e que não são de produção):

Trata-se da principal fase na qual as tarefas de migração propriamente ditas, conforme o definido no plano de migração, são realizadas pelos respectivos especialistas, nas áreas de vários tipos de software, como DB2, Lotus Domino ou WebSphere MQ.

  • O engenheiro de migração se certifica de que os sistemas de arquivos dos aplicativos e permissões no ambiente de destino sejam configurados da mesma forma que nos servidores de origem. Estas são algumas das principais atividades realizadas nesse momento:
    • configuração dos perfis de usuários e shells de login
    • configuração das variáveis de ambiente dos aplicativos
    • correção dos caminhos codificados permanentemente nos scripts dos aplicativos
  • Depois que o aplicativo estiver instalado corretamente no novo ambiente, faça as correções no código fonte dos aplicativos, conforme o determinado durante a fase do estudo de viabilidade e os resultados dos testes de unidade. Os principais motivos para a correção do código são as mudanças nos seguintes aspectos:
    • Sistema operacional
    • Compilador
    • Versões de software
    • Shell script de UNIX
  • Faça um teste de unidade minucioso antes da entrega do novo servidor para a equipe de aplicativos para a realização dos testes de aceitação pelos usuários.

Observação: o esforço e a complexidade do trabalho de correção do código e transferência são quase desprezíveis no ambiente de produção, porque a maior parte do trabalho já foi feita dos servidores de desenvolvimento.

Teste de integração de sistemas e teste de aceitação pelos usuários

Concluído o trabalho de migração, os aplicativos instalados e portados para o novo ambiente são entregues para a equipe do cliente para verificação e validação. Durante essa fase, a equipe de teste do cliente realiza os testes no nível do aplicativo para se certificar de que a funcionalidade de negócios não quebre e o nível de desempenho seja satisfatório. A equipe do cliente pode consultar a equipe de migração em relação a certas questões ou problemas durante esse teste.

Durante a fase de teste, o gerente de projeto de onda ou o engenheiro de avaliação designado terá uma função de coordenação, trabalhando com a equipe do cliente para:

  • Coletar diariamente o progresso do teste e o status dos defeitos junto à equipe de teste do cliente para auxiliar na resolução dos defeitos de push
  • Relatar o status de teste para a gerência e o escritório de projeto semanalmente
  • Auxiliar nas dependências de teste, os riscos e problemas

Entretanto, o gerente de projeto em ondas ou o engenheiro de avaliação designado não executará testes nem validará resultados, já que essa responsabilidade geralmente cabe à equipe de teste de aplicativo.

Transição dos servidores para a produção

Para os ambientes que não são de produção:

Concluídos os testes de aceitação pelos usuários, a equipe do cliente aprova os novos servidores. As tarefas pós-migração envolvem a remoção dos scripts customizados e arquivos que foram instalados temporariamente no novo servidor para ajudar na migração.

Para os ambientes de produção:

No ambiente de produção, um conjunto completamente novo de atividades de transição é iniciado nesse momento. Isso envolve encerrar os servidores de produção no ambiente de origem e iniciar a produção no novo ambiente. Durante essa transição, os usuários são afetados. Portanto, essa atividade geralmente é realizada durante a janela de manutenção dos aplicativos e principalmente nos fins de semana, para minimizar o tempo de inatividade dos aplicativos.

Um plano de transição baseado em planilha consiste nas seguintes seções:

  • Servidores lista os nomes dos servidores de produção que devem passar pela transição.
  • Pré-transição lista as tarefas que incluem a preparação para encerrar os servidores de origem, a verificação final do software instalado e dos arquivos de aplicativo no ambiente de produção, o backup de banco de dados na origem e a restauração no ambiente de destino, o envio das solicitações de mudança de URL e outras ações.
  • Transição lista a sequência real de encerramento dos aplicativos e tarefas em lote no ambiente de origem, a sua inicialização no ambiente de destino, a implementação das solicitações de mudança de URL/DNS, testes finais e notificação dos usuários sobre a disponibilidade do novo sistema.
  • Pós-transição lista a conclusão das atividades de transição. As tarefas estão relacionadas à coordenação das mudanças com o ambiente de produção anterior/posterior, conclusão de todas as tarefas de documentação restantes e monitoramento do novo ambiente até que ele seja estabilizado.
  • Retrocesso trata da eventualidade de uma falha no novo ambiente após a entrada em produção com uma provisão para voltar ao ambiente anterior. As etapas incluem o início do processo de retrocesso, a inicialização do software e do aplicativo no ambiente antigo, execução das tarefas em lote e o redirecionamento de URL/DNS para que aponte para os sistemas antigos.
  • Suposições lista quaisquer suposições relacionadas à transição, tais como:
    • Todos os programas, scripts e tabelas estão no ambiente de destino antes da movimentação de dados
    • Somente os dados de encerramento dos aplicativos são necessários para obter a produção no ambiente de destino
    • Todos os testes foram realizados para satisfazer a relocação no destino
  • Detalhes de contato indica todas as pessoas envolvidas na transição, juntamente com os detalhes de contato.
  • Problemas é uma documentação opcional dos problemas ocorridos durante a transição ou quaisquer comentários relevantes.

Comum aos ambientes de produção e os que não são de produção:

Verificação de funcionamento

A equipe de aplicativos é responsável pela realização de uma verificação de funcionamento no aplicativo para se certificar de que tudo está funcionando bem. Em seguida, a equipe de infraestrutura realiza uma verificação de funcionamento final nas imagens antes do go-live. Isso inclui fazer as correções de segurança, monitorar e certificar-se de que os backups estejam estabelecidos. Dependendo da quantidade de imagens envolvidas, isso pode levar de dois a quatro dias e deve ser planejado adequadamente. A equipe de infraestrutura terá que dar a aprovação na reunião de go-live, indicando que esses itens estão concluídos.


Pós-produção

Com os servidores na produção, a equipe de migração realiza duas etapas finais para fornecer um período de garantia e retirar de serviço os servidores antigos.

Garantia pós-transição

Com os servidores de destino na produção, a equipe de migração geralmente monitora o desempenho do novo ambiente e fica de prontidão para resolver problemas. Isso geralmente leva de dez dias a duas semanas e é conhecido como período de garantia. Durante esse período, o cliente tem acesso aos membros da equipe de migração para esclarecimentos ou resolução de problemas. Após o final do período de garantia, a equipe do cliente fica responsável por toda a manutenção e conservação do servidor.

Retirada de serviço ou desatribuição ou adaptação

Depois que os servidores que são de produção e os que não são de produção ficam operacionais e completam um número predefinido de dias sem grandes problemas ou tempo de inatividade, os servidores antigos são retirados de serviço e desatribuídos ou usados para outro fim.


Rastreamento

Durante todo o processo de migração, é essencial controlar as fases do projeto e a entrega de ponta a ponta. Por isso, é recomendável ter uma lista de verificação, normalmente conhecida como lista de verificação de painel técnico, um artefato baseado em Excel que contém os itens na Figura 7.

Figura 7. Lista de verificação de painel técnico
Lista de verificação de painel técnico

Na lista de verificação de painel técnico, a coluna Item/tarefa lista as atividades ou entregas, a saber, as tarefas na migração, transição e outros planos. Também lista os proprietários de cada tarefa, as datas pretendidas e datas de conclusão e o status de conclusão. Durante a fase de migração, de acordo com a melhor prática, o engenheiro de migração atualiza sua lista de verificação ao final de cada dia de trabalho para refletir o status atual de cada tarefa e entrega. Um esquema com código de cor (verde, amarelo e vermelho) ajuda a visualizar o funcionamento do projeto quando quiser.


Conclusão

Este artigo apresentou o conceito de migração de aplicativos, juntamente com as diretrizes de planejamento, preparação e, finalmente, implementação das atividades. Agora você tem uma boa noção das fases inteiras da migração, das principais decisões arquitetônicas necessárias e dos produtos do trabalho a serem preparados e sabe como evitar algumas armadilhas no processo.

Recursos

Aprender

Obter produtos e tecnologias

  • Avalie produtos IBM da maneira que for melhor para você: faça download da versão de teste de um produto, avalie um produto online, use-o em um ambiente de nuvem ou passe algumas horas no no Ambiente de Simulação da SOA para saber mais sobre como implementar arquitetura orientada a serviço (SOA) de maneira eficiente.

Discutir

Comentários

developerWorks: Conecte-se

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


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

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

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux, Software livre
ArticleID=828888
ArticleTitle=Acelere para a TI Verde: um Guia Prático para a Migração e Re-hospedagem de Aplicativos
publish-date=08062012