Implementando o plano de migração para o Azure

Atualizado: fevereiro de 2015

O Azure é uma plataforma de serviços e computação na escala da Internet hospedada em data centers da Microsoft. Com o Azure, desenvolvedores e administradores não precisam implementar o software subjacente e a infraestrutura de hardware já que todo o sistema operacional, o hardware, a rede, os recursos de armazenamento e as atualizações subjacentes da plataforma ficam a cargo da Microsoft automaticamente.

É altamente recomendável que depois de migrar seu aplicativo para a nuvem, você execute os testes funcionais e de desempenho em seu aplicativo assim como faria com qualquer aplicativo implantado recentemente. Como o Azure é diferente de suas plataformas locais, você deve considerar os seguintes problemas importantes ao implementar a migração:

Observe que o foco deste tópico é principalmente os Serviços de Nuvem do Azure. Para obter orientação preliminar sobre a migração com o SQL Server em máquinas virtuais do Azure, consulte Migrating with Azure Virtual Machines.

Autores: Kun Cheng, Steve Howard
Colaboradores: Selcin Turkarslan

Ao migrar seus aplicativos para a nuvem, você deve saber como testar e depurar seu aplicativo para ter a certeza de que ele funciona conforme o esperado na nuvem. Veja a seguir uma lista de abordagens que você pode usar para testar o aplicativo:

  • Ferramentas do Azure para Microsoft Visual Studio: Você pode criar seu aplicativo e, em seguida, executar e depurar esse aplicativo usando os emuladores de computação e armazenamento que são fornecidos como parte das Ferramentas do Azure. Isso permite desenvolver seu aplicativo localmente antes de publicá-lo no Azure. As Ferramentas do Azure para Microsoft Visual Studio estendem o Visual Studio 2010 e permitem testar seu aplicativo com os emuladores de computação e armazenamento, que fornecem a maioria das funções do Azure. É recomendável executar esse tipo de teste em fases iniciais de testes funcionais. Para obter mais informações, consulte Ferramentas do Azure para Microsoft Visual Studio.

  • SQL Server Data Tools: o SQL Server Data Tools (SSDT) oferece um ambiente integrado no Visual Studio 2010, que você pode usar para criar bancos de dados, criar ou editar objetos de banco de dados e dados ou executar consultas para todas as plataformas SQL com suporte; inclusive o Banco de Dados SQL do Azure fora do local e o Microsoft SQL Server 2012 local. Ele permite testar suas soluções de projeto de banco de dados usando o banco de dados padrão local ou o Banco de Dados SQL do Azure examinando a parte relacional de acesso a dados do aplicativo. Para obter mais informações, consulte SQL Server Data Tools. Observação: as ferramentas do Azure para Microsoft Visual Studio e SSDT permitem executar a funcionalidade básica e testes de compatibilidade em seu aplicativo com fontes de dados offline e online. Para testar todos os aspectos de um aplicativo real em nuvem em termos de funcionalidade, desempenho e escalabilidade, você precisa executar um teste de simulação no Azure em que o aplicativo é implantado e executado.

  • Estrutura de teste automatizada: muitos aplicativos existentes já têm uma estrutura automatizada de teste que pode ser usada para garantir que todos os componentes ou funções de aplicativo funcionem conforme o esperado. Quando um aplicativo é executado no Azure, a estrutura automatizada de teste pode ou não funcionar dependendo de como foi criada. Se a estrutura automatizada de teste for necessária para executar do local, mas puder se conectar a um aplicativo do Azure usando os pontos de extremidade definidos, ainda poderá funcionar. Caso contrário, recomendamos que você hospede a estrutura automatizada de teste e seu aplicativo no Azure para reduzir as perdas de conexão e problemas de latência potenciais.

  • Teste de carga do Visual Studio: se um aplicativo não tiver uma estrutura automatizada de teste, recomendamos que você crie um novo e use o Teste de carga do Visual Studio para fazer um teste de simulação com vários usuários simultâneos.

Entre teste, preparo e produção, tente minimizar o tempo real de transferência tanto quanto possível. Pode levar horas ou dias para copiar um banco de dados grande do local para o Azure. Além disso, é improvável que você queira que seu aplicativo fique inativo durante o tempo necessário para migrar completamente os dados existentes. Por isso, você deve ter um plano para minimizar o tempo de inatividade devido a transferência. Note que o tempo de transferência é o tempo necessário para executar a movimentação final para o Azure. Antes da transferência, observe suas tabelas e decida quais delas contêm dados estáticos e quais contêm dados que podem ser alterados durante a transferência. Para dados estáticos, você não precisa mover dados durante a transferência. Porém, se houver alguma dúvida sobre se os dados em uma tabela específica podem ou não ser alterados durante a transferência, você deverá incluir a lógica em seu sistema para migrar posteriormente todas as alterações. Recomendamos também considerar se todos os dados de seus sistemas locais precisam ser migrados para a nuvem antes que o aplicativo fique ativo no Azure. Se seu aplicativo puder ficar ativo e permitir que os dados sejam recuperados posteriormente, você poderá eliminar o tempo de inatividade.

No entanto, se os dados no Azure precisarem ser consistentes com os dados locais antes de ficarem ativos no Azure, minimize a quantidade de dados que devem migrar durante a transferência, porque isso ajuda a minimizar o tempo de inatividade necessário para a transferência real. Em alguns casos, pode ser apropriado mover alguns dos seus dados antes da transferência e, depois, mover os dados restantes após a transferência real. Nesses casos, seu plano de migração deve identificar claramente os dados que devem ser migrados primeiro e também os dados restantes que podem ser migrados após a transferência. Isso permite que o aplicativo fique ativo no Azure com menos tempo de inatividade porque seu aplicativo pode estar em produção enquanto você migra os dados restantes. É possível usar os seguintes métodos de sincronização de dados para executar a migração de dados antes da transferência:

Microsoft Azure O serviço Sincronização de Dados do SQL (Visualização) fornece recursos de sincronização de dados para Bancos de dados SQL: o SQL Server e o Banco de Dados SQL. O serviço tem atualmente dois recursos principais:

  • A sincronização de dados entre bancos de dados locais do SQL Server e instâncias do Microsoft Azure Banco de Dados SQL, permitindo que os aplicativos locais e baseados em nuvem utilizem dados idênticos.

  • A sincronização de dados entre duas ou mais instâncias do Microsoft Azure Banco de Dados SQL; as instâncias podem estar no mesmo data center, em data centers diferentes ou em regiões diferentes.

Microsoft Azure O Sincronização de Dados do SQL (Visualização) é uma boa opção para sincronizar bancos de dados locais e instâncias do Microsoft Azure Banco de Dados SQL nas seguintes situações:

  • Você precisa fazer testes paralelos de aplicativos.

  • Você precisa executar seu aplicativo em paralelo antes da movimentação final de todas as operações de dados locais para o Microsoft Azure.

  • Ao migrar para o Microsoft Azure, você precisa executar os aplicativos locais e, ao mesmo tempo, é necessário reduzir ao mínimo o tempo de inatividade.

  • Você precisa fazer a sincronização contínua de dados como parte de uma solução híbrida entre aplicativos locais e do Microsoft Azure.

Observe que, para rastrear as alterações dos dados incrementais, quando o grupo de sincronização é configurado, o Sincronização de Dados do SQL (Visualização) adiciona uma tabela de controle de alterações para cada tabela que está sendo sincronizada. Ao usar o Sincronização de Dados do SQL (Visualização), verifique se os planos de espaço consideram as tabelas de controle de alterações. Além disso, não faça alterações nas estruturas de tabela ou chaves primárias de tabelas que estão sendo sincronizadas antes de a sincronização ser configurada, a menos que você reinicialize o grupo de sincronização. O Sincronização de Dados do SQL (Visualização) não é o ideal para situações em que a sincronização de dados intermediária ou contínua é necessária.

Aviso: O Sincronização de Dados do SQL (Visualização) está disponível apenas como uma Visualização para fins de comentários sobre o produto para futuras versões e não deve ser usado em ambientes de produção.

Para obter mais informações sobre o Sincronização de Dados do SQL (Visualização), consulte Sincronização de Dados do SQL.

Você pode usar replicação, espelhamento ou envio de logs para mover dados do SQL Server local para outros SQL Server locais ou para uma instância do SQL Server executada em uma máquina virtual do Azure. Porém, você não pode usá-las para mover dados para dentro ou fora do Banco de dados SQL do Azure. Para obter mais informações, consulte Replicação e envio de logs e Espelhamento de banco de dados e envio de logs.

Para minimizar o tempo necessário para transferir dados no momento da transferência, você deverá mover o máximo possível de dados para a Plataforma Azure antes da transferência real. Você pode criar um trabalho personalizado de ETL para mover os dados alterados do sistema local para seu ambiente do Azure. Ao migrar de SQL Server 2008 ou posterior locais, recomendamos usar o Change Data Capture ou Change Data Tracking para garantir que todos os dados alterados, e nada mais do que os dados alterados, sejam movidos realmente do banco de dados local para a instância do Banco de dados SQL do Azure. Para obter mais informações sobre esses dois recursos, consulte Controlar alterações de dados nos Manuais Online do SQL Server. Para bancos de dados que não usam Change Data Capture ou Change Data Tracking, você precisa criar um sistema de controle para suas alterações e os dados que tiverem sido migrados. Em todos os casos, ter a quantidade mínima de dados para mover no momento da transferência real é essencial para minimizar o tempo de inatividade necessário.

Usando o DAC, você pode exportar dados de uma instância do SQL Server e colocá-los no armazenamento de Blob do Azure onde podem ser importados para um Banco de dados SQL do Azure. Com o DAC, você pode configurar filtros em que as tabelas devem ser importadas ou exportadas. Mas você não pode configurar filtros de nível de linha. É por isso que o DAC é apropriado quando tabelas inteiras se ajustam a um único banco de dados, mas não funcionam bem para bancos de dados em escala. O DAC não é ideal para migrar dados para aplicativos em que a sincronização intermediária ou contínua dos dados é necessária. Para obter mais informações, consulte Exportar um aplicativo da camada de dados nos Manuais online do SQL Server.

A finalidade de criar backups de banco de dados é permitir a recuperação da perda de dados causada por erros administrativos, erros de aplicativo ou a perda total de um data center. Fazer backup e restaurar dados no Banco de dados SQL do Azure são processos diferentes dos que ocorrem em um SQL Server local e devem funcionar com os recursos e as ferramentas disponíveis. Portanto, um uso confiável de backup e restauração para recuperação requer uma estratégia de backup e restauração do Banco de dados SQL do Azure. Há três categorias gerais de problemas dos quais uma instância do Banco de dados SQL do Azure pode precisar se recuperar:

  • Falhas de infraestrutura ou hardware: dentro de um data center, podem ocorrer falhas de hardware. Por exemplo, o nó físico que executa sua instância de Banco de dados SQL do Azure pode falhar.

  • Problemas ou falhas geradas pelo aplicativo ou pelo usuário: Usuários ou aplicativos podem fazer alterações indesejadas nos dados. Isso pode exigir uma operação de reversão. Por exemplo, um usuário poderia modificar alguns dados do cliente errado.

  • Perda de instalações de data center: o contrato de nível de serviço atual do Banco de dados SQL do Azure tem uma exceção especificamente para fatores fora do controle razoável da Microsoft, como desastres. No caso de desastre, o data center pode ser corrompido de forma que os bancos de dados não possam ser recuperados de réplicas ou de backups internos.

Você precisa finalmente decidir qual o nível de risco está disposto a tolerar com relação aos dados armazenados nos data centers do Banco de dados SQL do Azure. Para obter informações detalhadas sobre as ferramentas disponíveis de backup e restauração e como criar estratégias de recuperação de desastres em relação a elas, consulte o artigo Continuidade dos negócios no Banco de dados SQL do Azure na biblioteca do MSDN.

Quando você executa a migração real de seu aplicativo para o Azure, pode seguir as seguintes abordagens:

  • Executar em paralelo: com essa abordagem, seu aplicativo pode ser executado em paralelo no local e no Azure. Isso permite executar testes ao vivo em seu aplicativo no Azure antes de o aplicativo estar completamente dependente da nuvem. Os testes devem incluir, sem limitação, o seguinte: teste de funcionalidade, teste de desempenho e teste de escalabilidade. Depois de terminar de testar completamente o novo sistema no Azure, execute a migração de dados final e feche o seu sistema local.

  • Pausa e transferência: essa abordagem é apropriada quando todos os dados precisam ser sincronizados antes de ficarem totalmente ativos no Azure. Usando essa abordagem, todos os testes funcionais e de desempenho devem ser concluídos primeiro no Azure. Em seguida, configure seu sistema para replicar dados para seu ambiente do Azure usando um dos métodos de sincronização de dados especificados acima. Recomendamos que você mantenha os dados sincronizados o máximo possível minimizando a quantidade de tempo necessária para a última sincronização ou a operação de ETL anterior à transferência final. Quando for a hora de transferir para o Azure, derrube o sistema local, execute a última sincronização dos dados e ative seu aplicativo no Azure.

Consulte também

Mostrar: