Planejar a Migração
A arquitetura suporta vários cenários de migração.
Considerar Opções de Migração
Com o Oracle Exadata Database Service ou o Oracle Database Exadata Cloud at Customer, há quatro modelos de implantação comuns a serem considerados:
- Mova seu banco de dados grande e local para o Oracle Database Exadata Cloud at Customer "no estado em que se encontra", oferecendo também uma instância de DR (recuperação de desastres) do OCI conectada pelo Oracle Data Guard.
Componente No local Exadata (meio rack) Tamanho do banco de dados 47 TB 47 TB Núcleos 24 16 Área Global do Sistema e Área Global do Programa 4 TB 1,5 TB - Consolide vários bancos de dados locais para vários bancos de dados plugáveis (PDBs) no Oracle Exadata Database Service ou no Oracle Database Exadata Cloud at Customer, ao mesmo tempo em que fornece uma instância OCI DR conectada pelo Oracle Data Guard.
Componente No local Exadata (10 full rack) Bancos de Dados 1000 1000 Configuração do BD 2 a 16 TB por BD CDB = 29 PDB = 1000 de tamanhos variados
- Execute cargas de trabalho de produção no local usando o Oracle Database Exadata Cloud at Customer e forneça o DR ou o Oracle Exadata Database Service no OCI com as instâncias de banco de dados conectadas pelo Oracle Data Guard.
Componente No local Exadata (meio rack) Tamanho do banco de dados 19,5 TB 19,5 TB Núcleos 24 12 Área Global do Sistema e Área Global do Programa 2,5 TB 1,5 TB - Execute cargas de trabalho de produção no Oracle Exadata Database Service em OCI e DR usando hardware local com as instâncias de banco de dados conectadas pelo Oracle Data Guard.
Componente No local Exadata (meio rack) Tamanho do banco de dados 19,5 TB 19,5 TB Núcleos 24 12 Área Global do Sistema e Área Global do Programa 2,5 TB 1,5 TB
Usar Serviços Zero Downtime Migration
Para migrar seus bancos de dados locais grandes para o Oracle Cloud Infrastructure (OCI), considere o uso de serviços Zero Downtime Migration (ZDM).
Se você estiver usando o Oracle Exadata Database Service ou o Oracle Database Exadata Cloud at Customer, os dois envolverão a criação de um backup do banco de dados de origem e a restauração dele no banco de dados de destino. Em seguida, você precisa executar o RMAN, executar uma sincronização do Oracle Active Data Guard e alternar a atribuição principal do banco de dados de origem para o banco de dados de destino. O Zero Downtime Migration também suporta vários métodos de migração, com base em seu meio de backup escolhido. A mídia de backup pode ser o armazenamento do Oracle Cloud Infrastructure Object Storage, do Zero Data Loss Recovery Appliance ou do NFS (Network File System).
A tabela a seguir mostra os requisitos e as condições para vários cenários do Zero Downtime Migration (ZDM).
| Método de Migração | Tempo de Migração | Requisitos de tempo de inatividade* | Ferramentas Oracle usadas | Quando usar |
|---|---|---|---|---|
| ZDM - Físico On-line | 8 Horas |
2 a 5 minutos (independente do tamanho do banco de dados) |
|
|
| ZDM - Física Off-line | 8 Horas | Aprox. 8 horas por TB |
|
|
| ZDM - Lógico On-line | 12 Horas |
2 a 5 minutos (independente do tamanho do banco de dados) |
|
|
| ZDM - Lógico Off-line | 16 Horas | Aprox. 16 horas por TB |
|
|
* Esses números de tempo de inatividade são derivados de nossa experiência e devem ser usados como orientação geral, não como números exatos. Os requisitos de tempo de inatividade podem variar bastante, portanto é necessária uma análise e um teste completos antes de planejar uma transição de produção.
Recomendações
Seus requisitos podem ser diferentes da arquitetura descrita aqui. Use as recomendações a seguir como ponto de partida.
- VCN
Ao criar uma VCN, determine o número de blocos CIDR necessários e o tamanho de cada bloco com base no número de recursos que você planeja anexar às sub-redes na VCN. Use blocos CIDR que estão dentro do espaço de endereço IP privado padrão.
Selecione os blocos CIDR que não se sobrepõem a nenhuma outra rede (no Oracle Cloud Infrastructure, em seu data center local ou em outro provedor de nuvem) para a qual você pretende configurar conexões privadas.
Depois de criar uma VCN, você poderá alterar, adicionar e remover seus blocos CIDR.
Ao projetar as sub-redes, considere seu fluxo de tráfego e os requisitos de segurança. Anexe todos os recursos dentro de uma camada ou atribuição específica à mesma sub-rede, que pode servir como limite de segurança.
Use sub-redes regionais.
- Cloud Guard
Clone e personalize as receitas padrão fornecidas pela Oracle para criar receitas personalizadas do detector e do respondedor. Essas receitas permitem especificar que tipo de violações de segurança geram um aviso e quais ações podem ser executadas nelas. Por exemplo, talvez você queira detectar buckets do Object Storage que tenham visibilidade definida como pública.
Aplique o Cloud Guard no nível da tenancy para abranger o escopo mais amplo e reduzir a carga administrativa de manter várias configurações.
Você também pode usar o recurso Lista Gerenciada para aplicar determinadas configurações aos detectores.
- Zonas de Segurança
Para recursos que exigem segurança máxima, a Oracle recomenda que você use zonas de segurança. Uma zona de segurança é um compartimento associado a uma receita definida pela Oracle de políticas de segurança que se baseiam nas melhores práticas. Por exemplo, os recursos de uma zona de segurança não devem estar acessíveis pela internet pública e devem ser criptografados usando chaves gerenciadas pelo cliente. Quando você cria e atualiza recursos em uma zona de segurança, o Oracle Cloud Infrastructure valida as operações em relação às políticas na receita da zona de segurança e nega operações que violam qualquer uma das políticas.
Considerações
Quando você implanta bancos de dados locais no Oracle Cloud usando o Oracle Exadata Database Service, considere o seguinte:
- Migração com Tempo de Inatividade Zero (ZDM)
O ZDM pode ser executado no local e na nuvem. O ZDM suporta bancos de dados locais a serem migrados para uma variedade de destinos:
- Oracle Base Database Service
- Oracle Exadata Database Service em Infraestrutura Dedicada
- Oracle Exadata Database Service Cloud at Customer
- Oracle Exadata no local
- Oracle Autonomous Database
- Oracle Autonomous Transaction Processing (Dedicado e Compartilhado)
- Oracle Autonomous Data Warehouse (Dedicado e Compartilhado)
- ZDM e Oracle Cloud Infrastructure Database Migration Service (DMS)
As principais diferenças entre ZDM e DMS são:
-
O ZDM funciona como o mecanismo principal que suporta a maioria dos métodos/fontes/destinos e é baseado em uma interface de linha de comando (CLI).
-
O DMS usa o ZDM sob as capas e permite a migração lógica off-line/on-line com uma interface do usuário para serviços de banco de dados nativos do OCI.
-
A Migração de Banco de Dados é um serviço totalmente gerenciado que fornece uma experiência de autoatendimento de alto desempenho para migrar bancos de dados para a OCI (Oracle Cloud Infrastructure).
-
A Migração de Banco de Dados do OCI é executada como um serviço de nuvem gerenciado, separado da sua tenancy e recursos. O serviço opera como um serviço multitenant em uma tenancy do serviço Database Migration e se comunica com seus recursos usando pontos finais privados (PEs). Os PEs são gerenciados pelo serviço Database Migration.
-
- Tamanho do banco de dados
Não há restrições de tamanho para ZDM ou DMS. A restrição teórica será o tamanho máximo do Oracle Database que seu sistema operacional pode ter. O número máximo de arquivos de dados e o tamanho máximo de um arquivo de dados dependem do sistema operacional.
Para uma pequena migração de banco de dados de terabyte (<1) para um Autonomous Database, você pode usar o método lógico off-line ou on-line do ZDM, dependendo dos seus requisitos de tempo de inatividade. A opção lógica on-line requer apenas alguns minutos de tempo de inatividade, enquanto a opção lógica off-line leva algumas horas de inatividade, dependendo do tamanho do banco de dados.
Para um banco de dados local de tamanho igual ou superior a 400 TB, a migração será do local para o Oracle Exadata Database Service Cloud at Customer (que também estará no data center do cliente). Use a migração on-line física do ZDM para manter seu tempo de inatividade baixo e reduzir o risco durante a migração com o uso do Data Guard. No entanto, os bancos de dados de origem e de destino terão que estar na mesma versão. Se você quiser fazer um upgrade em andamento de uma versão inferior para uma versão superior, use o método on-line lógico do ZDM. Qualquer método off-line incorrerá em um grande tempo de inatividade, que pode não ser aceitável para o seu negócio.
- Data Guard e Active Data Guard
O Data Guard (DG) e o Active Data Guard (ADG) fornecem um conjunto abrangente de serviços que criam, mantêm, gerenciam e monitoram um ou mais bancos de dados standby para permitir que os bancos de dados Oracle primários sobrevivam a desastres e danos aos dados. Os bancos de dados em espera são mantidos como cópias do banco de dados de produção. No entanto, com o ADG, você pode abrir seu banco de dados standby para somente leitura (por exemplo, para fins de relatório) enquanto ele está sendo mantido em sincronia com o banco de dados principal. Com o DG, você deve pausar o processo de sincronização para abrir seu banco de dados stand-by no modo somente leitura.
- Virtualização do Exadata
Você pode virtualizar o Exadata em uma máquina virtual ou pode executar uma instalação bare metal. A arquitetura das opções pode ser significativamente diferente. Com uma instalação bare metal, você tem um cluster Oracle para uma máquina Exadata inteira, a menos que você particione fisicamente sua máquina Exadata. Com uma máquina Exadata virtualizada, você tem um domínio de gerenciamento (dom0) e pelo menos um domínio de usuário (domU), dependendo do número de clusters de VMs que estão sendo implantados.
- Teste Real de Aplicativos (RAT)
Consulte o link na seção Explorar Mais.