Migrar cargas de trabalho do Oracle para o Azure
Como parte de sua jornada de adoção da nuvem, você deve migrar suas cargas de trabalho existentes para a nuvem. Cargas de trabalho oracle são semelhantes a outras cargas de trabalho e exigem uma abordagem metódica para ajudar a garantir uma migração bem-sucedida. Para obter mais informações sobre a metodologia de migração, consulte Migração na Nuvem no Cloud Adoption Framework para o Azure. Este artigo descreve restrições e considerações específicas às cargas de trabalho do Oracle.
Cenários de migração do Oracle
Ao migrar cargas de trabalho oracle, você precisa fazer a transição de bancos de dados e aplicativos. Este artigo discute a abordagem lift-and-shift para migrações de aplicativo e banco de dados. A abordagem lift-and-shift inclui a implantação de aplicativos Oracle em Máquinas Virtuais do Azure. Para a migração de banco de dados, várias opções estão disponíveis. Este artigo fornece diretrizes que se aplicam a Oracle Database@Azure.
Aplicativos em Máquinas Virtuais: Execute aplicativos empresariais da Oracle, como Siebel, PeopleSoft, JD Edwards, E-Business Suite ou aplicativos personalizados do WebLogic Server na infraestrutura do Azure.
Bancos de Dados Oracle Standard Edition ou Enterprise Edition em Máquinas Virtuais: Neste cenário, você implantará seu Banco de Dados Oracle em uma Máquina Virtual. Há várias opções disponíveis, desde bancos de dados autogerenciados até gerenciados. Se preferir uma solução de banco de dados gerenciada, examine Tessell.
Oracle Database@Azure: Oracle Database@Azure é um serviço de banco de dados Oracle executado no Oracle Cloud Infrastructure (OCI) e que é colocado em datacenters da Microsoft.
Nota
Para determinar sistemas operacionais com suporte para sua versão de banco de dados específica, consulte bancos de dados e sistemas operacionais com suporte.
O processo de migração Oracle
Você deve reavaliar continuamente seus requisitos de infraestrutura para melhorar o desempenho e reduzir custos usando o tipo de serviço relevante para sua carga de trabalho. Por exemplo, para todos os cenários mencionados anteriormente, verifique se a largura de banda suficiente está disponível para sua migração. Recomendamos que você examine a largura de banda necessária ao realizar uma poc (prova de conceito).
Se você mover sua carga de trabalho para o Oracle em Máquinas Virtuais, verifique se os tamanhos da VM (máquina virtual) atendem aos seus requisitos. Para obter mais informações, confira Planejamento de capacidade para migrar cargas de trabalho Oracle para zonas de destino do Azure.
Revise os recursos de migração para definir o processo de migração do Oracle para o Azure. Também é possível:
- Verifique os limites de cota de assinatura do Azure: Verifique se os limites de cota em sua assinatura do Azure podem acomodar os tamanhos de VM de destino escolhidos se você migrar para o Oracle em Máquinas Virtuais.
Nota
Se você hospedar sua carga de trabalho no Oracle Database@Azure e precisar de um aumento de cota, consulte o contato do Oracle.
Identificar um modelo de implantação: Automatizar a implantação de componentes de solução o máximo possível usando a infraestrutura como código, integração contínua e pipelines de entrega contínua e outras práticas de DevOps.
Determinar dependências do aplicativo: Verifique se as atividades de migração são o mais não disruptivas possível.
Identifique a capacidade de dados: Identifique a quantidade de dados a serem migrados e avalie a capacidade atual de conectividade de rede disponível de ambientes locais para o Azure. Use essas informações para determinar se você pode copiar os dados diretamente de ambientes locais para o Azure. Pode ser necessário um dispositivo de transferência de dados físico, como o Azure Data Box, para o carregamento inicial de dados.
Determinar os requisitos de disponibilidade: Determinar os requisitos de disponibilidade da carga de trabalho porque eles podem afetar as ferramentas de migração que você pode usar. Defina seu tempo de inatividade máximo aceitável. Essa métrica ajuda você a definir suas ferramentas de migração e abordagem.
Essa consideração se aplica igualmente ao seu aplicativo. Se você não puder aceitar uma interrupção em suas operações diárias, precisará executar uma migração online.
- Determine suas ferramentas para migrar sua carga de trabalho para o Oracle em máquinas virtuais do Azure: os dois caminhos de migração principais estão offline e online.
| Migração offline | Migração online |
|---|---|
| Cópia direta única do banco de dados. | Cópia inicial do banco de dados seguida pela captura de dados de alteração durante a migração. |
| Requer que o aplicativo afetado fique offline durante a migração. | O aplicativo pode permanecer online durante a migração. |
| Ferramentas de usadas: Data Box, DataPump, Oracle Recovery Manager (RMAN) | Ferramentas usadas: DataGuard, Oracle Recovery Manager (RMAN), GoldenGate |
Nota
Se você decidir executar uma migração online, configure as regras de firewall para permitir a transferência de dados.
Atividades específicas da carga de trabalho de migração Oracle
A seção a seguir descreve o processo de migração em detalhes. As etapas não são necessariamente sequenciais. Você pode executar algumas etapas em paralelo.
Avaliar as versões do sistema de origem e de destino: Avaliar se as versões do sistema operacional local (sistema operacional), versões de aplicativo e versões de banco de dados são as mesmas locais e no Azure.
Se você precisar atualizar um ou mais recursos, atualize-os antes da migração para simplificar o processo de migração.
Se o banco de dados local for executado em um sistema operacional big-endian, como Oracle Solaris, IBM Advanced Interactive eXecutive ou Hewlett Packard Unix, o processo de migração do banco de dados incluirá uma conversão endian. O Azure dá suporte apenas a sistemas operacionais little-endian. Essa limitação reduz o número de ferramentas disponíveis para a migração. Especificamente, você não pode usar o Oracle Data Guard nem outro método de cópia de arquivo. Os métodos de migração compatíveis com a conversão endian incluem o Oracle Data Pump Export e o Oracle Data Pump Import, tablespaces transportáveis multiplataforma Oracle (XTTS) ou utilitários de replicação de dados, como Oracle GoldenGate, Quest SharePlex e Striim.
Você pode modernizar ou migrar servidores de aplicativos locais, dependendo dos requisitos e da compatibilidade. Para obter mais informações, confira Cenários de adoção de nuvem.
Avaliar os requisitos de disponibilidade da carga de trabalho durante o processo de migração: Se você precisar minimizar o tempo de inatividade da carga de trabalho, métodos de migração como Exportação de Bomba de Dados ou Importação de Bomba de Dados podem não atender à carga de trabalho. Nesse caso, siga este processo de quatro etapas:
Use o RMAN para fazer backup e restaurar todo o banco de dados no Azure. Execute uma conversão endian por meio do XTTS, se necessário. O resultado é um banco de dados que é uma cópia pontual do banco de dados de origem local. Para obter mais informações, confira Transporte de dados entre plataformas.
Se ambas as fontes forem de formato pouco endiano, use o Oracle Data Guard para sincronizar o banco de dados recém-restaurado no Azure com o banco de dados de origem. Não é possível usar o Data Guard se a migração incluir a conversão de big-endian para little-endian. Em vez disso, use um utilitário de replicação de dados baseado em SQL, como Oracle GoldenGate, Quest SharePlex ou Striim, para sincronizar o banco de dados recém-restaurado no Azure com o banco de dados de origem.
Depois de sincronizar o banco de dados de destino no Azure com o banco de dados local de origem, você pode agendar uma substituição. Uma substituição desliga o banco de dados local de origem e libera as últimas transações para o banco de dados de destino no Azure. Em seguida, você pode abrir o banco de dados de destino no Azure como o novo banco de dados de origem. Uma substituição pode levar apenas alguns minutos, dependendo do método de sincronização usado.
Dependendo da abordagem de migração escolhida para os serviços de aplicativo, talvez seja necessário concluir várias tarefas de serviço de aplicativo antes de migrar totalmente o aplicativo para o Azure.
Avaliar as licenças necessárias: Seu banco de dados pode exigir várias licenças, dependendo das ferramentas de migração. Por exemplo:
O Oracle Data Guard requer o Oracle Database Enterprise Edition.
O Oracle GoldenGate requer licenças do Oracle GoldenGate.
Para saber mais sobre o licenciamento do Oracle no Azure, confira Licenciamento do software Oracle no Ambiente de Computação em Nuvem.
Diretrizes de migração do Oracle Database@Azure
Verifique se a solução Oracle Database@Azure está disponível na região em que você deseja implantar a solução. Para obter mais informações, confira Regiões disponíveis.
Considere usar o Oracle Zero Downtime Migration para o processo de migração. Avalie as estratégias de migração para determinar a abordagem mais adequada para seus requisitos específicos de migração. Para obter mais informações, confira Migração com tempo de inatividade zero (ZDM). O ZDM fornece a capacidade de escolher cenários de migração lógica ou física. Para obter mais informações, confira Migração ZDM.
Nota
Se você escolher o Serviço de Banco de Dados Autônomo (ADB-S), tenha em mente que há suporte apenas para cenários de migração lógica.
Outras diretrizes
A seção a seguir pode ajudá-lo a escolher a opção de migração correta para seus requisitos e tamanhos de dados.
Referência de duração da migração baseada no ExpressRoute
A tabela a seguir serve apenas como uma linha de base. Ele não considera outras cargas de trabalho de produção executadas pela mesma conexão do Azure ExpressRoute.
O VMware pode precisar de mais largura de banda do que o indicado. Avalie suas necessidades de largura de banda durante a etapa de PoC. Se você precisar de suporte, entre em contato com seu contato local.
| Tamanho dos dados | Largura de banda de 1 Gpbs | Largura de banda de 10 Gbps |
|---|---|---|
| 1 TB | 3 horas | 15 min |
| 10 TB | 1 dia | 3 horas |
| 35 TB | 4 dias | 9 horas |
| 80 TB | 8 dias | 20 horas |
| 100 TB | 11 dias | 1 dia |
| 200 TB | 21 dias | 2 dias |
| 500 TB | 53 dias | 5 dias |
Se você planeja usar o ExpressRoute para sua migração, verifique se sua resiliência atende aos seus requisitos.