Migrar cargas de trabalho 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. As 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 para a Nuvem no Cloud Adoption Framework para Azure. Este artigo descreve restrições e considerações específicas para cargas de trabalho Oracle.
Cenários de migração 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 aplicativos e bancos de dados. A abordagem lift-and-shift inclui a implantação de aplicativos Oracle em Máquinas Virtuais do Azure. Para migração de banco de dados, várias opções estão disponíveis. Este artigo fornece orientação que se aplica ao Oracle Database@Azure.
Aplicativos em máquinas virtuais: Execute aplicativos empresariais 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: Nesse cenário, você implanta seu banco de dados Oracle em uma máquina virtual. Há várias opções disponíveis, desde bancos de dados autogerenciados até bancos de dados gerenciados. Se preferir uma solução de banco de dados gerenciado, consulte Tessell.
Oracle Database@Azure: Oracle Database@Azure é um serviço de banco de dados Oracle que é executado no Oracle Cloud Infrastructure (OCI) e que está localizado em datacenters da Microsoft.
Observação
Para determinar os sistemas operativos suportados para a sua versão específica da base de dados, consulte bases de dados e sistemas operativos suportados.
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 há largura de banda suficiente disponível para a migração. Recomendamos vivamente que reveja a largura de banda necessária quando realiza uma prova de conceito (PoC).
Se você mover sua carga de trabalho para Oracle em máquinas virtuais, certifique-se de que os tamanhos de máquina virtual (VM) atendam às suas necessidades. Para obter mais informações, consulte Planejamento de capacidade para migrar cargas de trabalho Oracle para zonas de aterrissagem do Azure.
Analise os recursos de migração para definir seu processo de migração do Oracle para o Azure. Também pode:
- Verificar limites de cota de assinatura do Azure: Certifique-se de que os limites de cota em sua assinatura do Azure possam acomodar os tamanhos de VM de destino escolhidos se migrar para o Oracle em Máquinas Virtuais.
Observação
Se você hospeda sua carga de trabalho no Oracle Database@Azure e precisa de um aumento de cota, consulte seu contato da Oracle.
Identificar um modelo de implantação: Automatize a implantação de componentes da solução tanto quanto possível usando infraestrutura como código, integração contínua e pipelines de entrega contínua e outras práticas de DevOps.
Determinar dependências de aplicativos: Garantir que as atividades de migração sejam o mais sem interrupções possível.
Identificar a capacidade de dados: Identifique a quantidade de dados a migrar e avalie a capacidade de conectividade de rede disponível atual 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. Você pode precisar de um dispositivo de transferência de dados físico, como o Azure Data Box , para a carga inicial de dados.
Determinar requisitos de disponibilidade: Determine os requisitos de disponibilidade da carga de trabalho porque eles podem afetar as ferramentas de migração que você pode usar. Defina o tempo de inatividade máximo aceitável. Essa métrica ajuda você a definir suas ferramentas e abordagem de migração.
Esta consideração aplica-se igualmente à sua candidatura. Se você não pode aceitar uma interrupção em suas operações diárias, você precisa realizar uma migração online.
- Determine suas ferramentas para migrar sua carga de trabalho para Oracle em máquinas virtuais do Azure: Os dois principais caminhos de migração sã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 de captura de dados de alteração durante a migração. |
| Requer que o aplicativo afetado esteja offline durante a migração. | O aplicativo pode permanecer online durante a migração. |
| Ferramentas utilizadas: Data Box, DataPump, Oracle Recovery Manager (RMAN) | Ferramentas utilizadas: DataGuard, Oracle Recovery Manager (RMAN), GoldenGate |
Observação
Se você decidir executar uma migração online, certifique-se de configurar 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 com mais 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: Avalie se as versões do sistema operacional (SO) local, as versões do aplicativo e as versões do banco de dados são as mesmas no local 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 seu 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 suporta apenas sistemas operativos 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 ou qualquer outro método de cópia de arquivo. Os métodos de migração compatíveis com a conversão endian incluem Oracle Data Pump Export ou Oracle Data Pump Import, Oracle cross-platform transportable tablespaces (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, consulte 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, os métodos de migração, como Data Pump Export ou Data Pump Import, podem não se adequar à sua 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 através de XTTS, se necessário. O resultado é um banco de dados que é uma cópia point-in-time do banco de dados de origem local. Para obter mais informações, consulte Transporte de dados entre plataformas.
Se ambas as fontes forem de formato little-endian, 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 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 transição pode demorar apenas alguns minutos, dependendo do método de sincronização que utilizar.
Dependendo da abordagem de migração escolhida para 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 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 obter mais informações sobre o licenciamento Oracle no Azure, consulte Licenciamento de 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 onde você deseja implantar a solução. Para obter mais informações, consulte Regiões disponíveis.
Considere o uso do Oracle Zero Downtime Migration para o processo de migração. Avalie as estratégias de migração para determinar a abordagem mais adequada aos seus requisitos específicos de migração. Para obter mais informações, consulte Zero Downtime Migration (ZDM). O ZDM oferece a capacidade de escolher cenários de migração lógica ou física. Para obter mais informações, consulte migração do ZDM.
Observação
Se você escolher Serviço de Banco de Dados Autônomo (ADB-S), lembre-se de que apenas cenários de migração lógica são suportados.
Outras orientações
A seção a seguir pode ajudá-lo a escolher a opção de migração certa para seus requisitos e tamanhos de dados.
Referência de duração da migração baseada em ExpressRoute
A tabela a seguir serve apenas como linha de base. Ele não considera outras cargas de trabalho de produção que são executadas através da 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 fase de PoC. Se 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 minutos |
| 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 planear utilizar o ExpressRoute para a sua migração, assegure-se de que a sua resiliência atende aos seus requisitos.