Exportar (0) Imprimir
Expandir Tudo

Visão geral do ciclo de vida da migração no Azure

Atualizado: abril de 2014

O ciclo de vida da migração é uma metodologia padrão que fornece as instruções passo a passo sobre como migrar seus aplicativos e dados para o . As principais etapas da migração são a fase de análise, a fase de migração do aplicativo, a fase de migração de dados, a fase de teste e otimização, e a fase da operação e gerenciamento, conforme mostrado no diagrama abaixo.

Este tópico explica detalhadamente cada fase com links para informações adicionais.

O também oferece suporte ao Oracle em Máquinas Virtuais do . Para obter mais informações, consulte Imagens de Máquinas Virtuais Oracle para Azure

Autores: Kun Cheng, Selcin Turkarslan, Norberto Garcia
Revisores: Paolo Salvatori, Steve Howard, Stuart Ozer

O objetivo dessa fase é compreender as necessidades comerciais que exigem a solução . Depois de identificar os objetivos comerciais, examine a arquitetura do aplicativo existente para identificar as principais diferenças entre o e as soluções locais, e determinar se você precisa recriar o design do aplicativo local existente para atender às necessidades comerciais de uma solução . As seguintes tarefas e perguntas ajudam a criar um plano de migração:

  • Definir requisitos de negócios: há muitas questões potenciais geradas por cenários de negócios quando um aplicativo é executado no :

    • A solução de implantação do está voltada para novos clientes e usuários?

    • Ela exigirá multilocação para oferecer suporte a vários clientes?

    • O aplicativo está atendendo aos regulamentos de conformidade quando os dados estão hospedados no data center da Microsoft em vez de sites do cliente?

    • Quais aplicativos são mais adequados para a nuvem arquitetônica e estrategicamente?

    • Que tipo de migração atende melhor ao meu aplicativo: migrar um aplicativo inteiro e todas as dependências para o ; ou migrar uma parte do aplicativo para a nuvem enquanto alguns recursos permanecem no local; ou migrar um aplicativo para a função Web ou de trabalho com dependências que funcionem melhor em uma Máquina Virtual do .

    As respostas a essas perguntas afetam a maneira como um aplicativo se comporta na plataforma do .

  • Determinar as discrepâncias de recursos: você consegue executar o aplicativo existente no sem alterações? Por exemplo, o Banco de dados SQL do (Banco de dados SQL) não oferece suporte a todos os recursos que têm suporte do SQL Server local. Se você quiser mover um aplicativo local que usa CLR (common language runtime) para o banco de dados SQL, precisará recriar o design do aplicativo movendo a lógica de CLR do SQL Server para a camada de aplicativo, ou reescrevendo a lógica de CLR usando as instruções Transact-SQL que têm suporte do banco de dados SQL. Observe que o Banco de dados SQL no momento não oferece suporte a SQL CLR.

    A partir da versão 2012, novos recursos de Máquina Virtual foram adicionados ao . Com as Máquinas Virtuais do , você pode migrar aplicativos existentes do SQL Server criados na plataforma do Windows Server para a plataforma do com pouca ou nenhuma alteração de código. Com o SQL Server na Máquina Virtual do , administradores e desenvolvedores ainda podem usar as mesmas ferramentas de desenvolvimento e administração que estão disponíveis localmente. O desempenho de um banco de dados relacional na máquina virtual depende de muitos fatores, inclusive o tamanho da máquina virtual, o número e a configuração dos discos, a rede, a configuração do software de banco de dados e a carga de trabalho do aplicativo. Recomendamos que os desenvolvedores do aplicativo façam a comparação entre vários tamanhos de máquina virtual e configurações de armazenamento para selecionar o mais apropriado. Para obter mais informações, consulte Migrando para o SQL Server em uma máquina virtual do Azure.

  • Preparar um plano para desempenho e escalabilidade: muitos aplicativos herdados foram criados para serem totalmente integrados entre a lógica de aplicativo e os componentes de acesso a dados. Para aplicativos herdados, faz sentido desacoplar componentes do aplicativo para executar e dimensionar melhor no . Se o aplicativo for muito verborrágico ou fizer consultas excessivas a dados, use o Serviço de Caching do Azure ou implemente seu próprio mecanismo de cache para processar em lotes consultas de acesso a dados e reduzir viagens de ida e volta entre os dados e o aplicativo. Se o aplicativo de negócios a ser migrado lida com bancos de dados grandes ou alto volume de transações, migrar para o banco de dados SQL provavelmente exigirá um novo design do modelo de banco de dados. Isso ocorre porque uma única instância de banco de dados SQL pode lidar com um número limitado de transações por segundo e tem um tamanho de banco de dados limitado. Ao lidar com grandes bancos de dados ou alto volume de transações, considere implementar uma arquitetura de expansão utilizando vários bancos de dados no banco de dados SQL ou comece a usar métodos de expansão em vez de sistemas de expansão locais caros. Considere a implementação de OLTP na memória ou a durabilidade adiada de tabelas com grandes volumes de transações como forma de melhorar o desempenho. Para obter mais informações sobre o OLTP na memória, consulte OLTP na memória (otimização da memória). Para obter mais informações sobre a durabilidade adiada, consulte Controlar a durabilidade da transação.

    Para obter mais informações sobre considerações de desempenho ao usar o SQL Server em uma máquina virtual, consulte Considerações de desempenho do SQL Server em Máquinas Virtuais do Azure e o artigo Orientações sobre desempenho do SQL Server em Máquinas Virtuais do Azure.

    O Banco de dados SQL do lançou uma visualização Premium limitada do Banco de dados SQL. Ao reservar uma quantidade fixa de capacidade para seu Banco de dados SQL e suas réplicas secundárias, o serviço Premium proporcionará um desempenho mais previsível para aplicativos de nuvem, relativo às edições Banco de dados SQL Web e Business existentes. Para obter mais informações sobre as contas Premium do Banco de dados SQL, consulte Gerenciando um banco de dados Premium e Visualização Premium para a orientação de Banco de dados SQL.

  • Preparar um plano para o gerenciamento do ciclo de vida do aplicativo: é importante considerar cenários de controle de versão e atualização de aplicativos no . Dependendo de seu contrato de nível de serviço, talvez seja necessário manter várias versões do seu aplicativo para oferecer suporte a diferentes camadas de clientes. Talvez você também queira minimizar o tempo de inatividade ao atualizar um aplicativo no . É recomendável fazer a manutenção cuidadosa do ambiente de preparo e do ambiente de produção no . Verifique se você é capaz de reverter as atualizações em caso de problemas de compatibilidade. Seu plano de reversão de atualização deve abranger primeiro o aplicativo e, em seguida, o banco de dados.

Depois dessa fase, recomendamos que você crie um projeto piloto porque ele oferece uma compreensão clara dos serviços e das ferramentas da Plataforma .

Quando decidir migrar seu aplicativo para o , comece com uma versão piloto do aplicativo com dados mínimos para criar uma prova de conceito. Primeiro, implemente as alterações necessárias de código em seu aplicativo para atender às metas de implantação do em termos de requisitos comerciais e técnicos. Em seguida, compile e implante o código do aplicativo nas funções apropriadas no .

Em geral, a maioria dos aplicativos existentes locais podem ser executados em Serviços de Nuvem do com pouca ou nenhuma alteração, mas isso pode gerar alguns problemas de desempenho, escalabilidade e segurança. Para otimizar o desempenho e permitir a escalabilidade futura, é recomendável recriar o design de seu aplicativo usando várias funções antes de migrar para os Serviços de Nuvem do . Para obter mais informações, consulte Considerações de desenvolvimento para os Serviços de Nuvem do Azure. É recomendável primeiro mover o aplicativo inteiro para os Serviços de Nuvem do e, em seguida, os dados. Devido a motivos de segurança, desempenho ou outros, algumas partes do aplicativo podem precisar permanecer no local. Isso exige soluções híbridas. Para obter mais informações, consulte Criando soluções híbridas com o Azure.

Se você decidir usar o SQL Server em uma Máquina Virtual (VM) do , modifique os aplicativos existentes do SQL Server para se conectar com o Banco de dados do SQL Server na Máquina Virtual do . Além disso, siga uma das seguintes abordagens de migração:

  • Você pode ter um aplicativo já funcionando em uma máquina virtual existente. Você pode migrar essa máquina virtual para o . Nesse caso, o aplicativo, seus parâmetros de configuração e os dados já estão nessa máquina virtual. Mas isso pode exigir o carregamento de um arquivo .vhd grande no . Além disso, pode haver alguns drivers e dependências de hardware nessa máquina virtual existente, e eles podem não estar disponíveis no .

  • Você pode criar uma máquina virtual no . Para fazer isso, você pode iniciar uma máquina virtual da Galeria de Imagens, que já contém o SQL Server. Em seguida, instale os seus aplicativos nela. Isso reduz o tempo de carregamento e remove as dependências de driver e hardware, mas requer a instalação do aplicativo e o carregamento de dados.

Para obter mais informações sobre como migrar os Bancos de dados do SQL Server existentes para um SQL Server na máquina virtual do , consulte o tópico Migrando para o SQL Server em uma máquina virtual do Azure.

Se você usar Serviços de Nuvem do , mova os dados relacionais do SQL Server local para o Banco de dados SQL, e mova os dados não estruturados para o armazenamento do como Blob, Tabela ou Unidades do . Para obter mais informações, consulte Migrando dados para tabelas e Blobs no Windows Azure e Migrando bancos de dados do SQL Server para o Banco de dados SQL do Azure.

Se você decidir usar o SQL Server em Máquinas Virtuais do , poderá seguir uma destas duas abordagens de migração:

  • Você pode ter dados em uma máquina virtual existente. Você pode carregar essa máquina virtual existente em um arquivo .vhd no .

  • Você pode criar uma máquina virtual no . Em seguida, você pode carregar dados de um arquivo .vhd no . Em seguida, você pode anexar este arquivo .vhd carregado ou um disco vazio à máquina virtual como um disco de dados. Você pode usar os discos de dados para armazenar os logs e os arquivos de dados do SQL Server. Além disso, você pode usar as ferramentas e as técnicas que são descritas no tópico Migrando para o SQL Server em uma máquina virtual do Azure para migrar os Bancos de dados do SQL Server existentes para um SQL Server em uma máquina virtual do .

Após migrar o aplicativo e os dados para o , execute testes funcionais e de desempenho. Nesta fase, teste o seu aplicativo na nuvem e confirme que ele funciona conforme o esperado. Em seguida, compare os resultados de desempenho entre o local e o . Depois disso, resolva qualquer problema de recurso, funcionalidade, desempenho ou escalabilidade em seu aplicativo na nuvem. Para obter mais informações, consulte Implementando o plano de migração para o Azure.

Depois da fase de teste e otimização, configure e implemente o monitoramento e o rastreamento do aplicativo com o Diagnóstico do . O Diagnóstico do permite coletar dados de diagnóstico de um aplicativo em execução no . Você pode usar dados de diagnóstico para depurar e solucionar problemas, medir o desempenho, monitorar o uso de recursos, fazer a análise de tráfego e o planejamento de capacidade e fazer a auditoria. Para obter mais informações, consulte Diagnóstico e depuração no Azure na biblioteca do MSDN.

Se você precisar sincronizar dados entre o local e o banco de dados SQL ou entre servidores de banco de dados SQL diferentes, configure o serviço Sincronização de Dados do SQL (Visualização). Além disso, recomendamos que você configure o plano de recuperação de dados em caso de erros do usuário ou desastres naturais. Para obter mais informações, consulte Considerações sobre alta disponibilidade e recuperação de desastres com Banco de dados SQL do Azure.

Consulte também

Mostrar:
© 2014 Microsoft