Projetar aplicativos Oracle
A migração de aplicativos Oracle para a nuvem é um processo complexo. Você precisa entender quais funcionalidades cada versão de um aplicativo suporta para evitar problemas durante a migração ou até mesmo evitar uma migração com falha. As organizações não querem apenas levantar e mudar aplicativos. Eles também querem modernizar a arquitetura e se alinhar com os requisitos funcionais e não funcionais. Você deve examinar esses requisitos juntamente com os principais padrões de design de aplicativos em nuvem para garantir que você atinja suas metas de migração.
Exemplos de aplicativos Oracle populares são Siebel, E-Business Suite, JD Edwards e PeopleSoft. Esses aplicativos têm fortes dependências entre a camada de aplicativo e a camada de banco de dados. Separar as duas camadas em diferentes fornecedores de nuvem introduz latências que podem levar a uma experiência ruim para os clientes. Você deve sempre fazer uma avaliação técnica adequada antes de decidir como hospedar os dois níveis.
Para cada aplicativo, você deve observar as considerações de design que o fornecedor do aplicativo fornece e considerar as características dos serviços do Azure que você usa para cada design. A nuvem do Azure oferece muitos recursos e funcionalidades que podem levar a uma solução de alto desempenho, confiável, segura e altamente disponível.
Para obter diretrizes de arquitetura mais específicas, consulte Arquiteturas para aplicativos Oracle com um banco de dados em Máquinas Virtuais do Azure.
Recomendações
Use as recomendações a seguir para planejar a migração de seus aplicativos Oracle para a nuvem.
Rede e segurança
- Considere configurar o SSO (logon único) usando a ID do Microsoft Entra. Os clientes podem usar o SSO para se conectar a aplicativos Oracle por meio de seu navegador de internet. Para obter mais informações, consulte Habilitar SSO para um aplicativo empresarial.
- Considere usar uma conexão privada com a instalação na nuvem. O Azure fornece recursos de conectividade privada, como conexões do Azure ExpressRoute e conexões VPN site a site.
- Se um cliente acessar o aplicativo pela Internet, considere um gateway de aplicativo. O Gateway de Aplicativo do Azure fornece duas funcionalidades internas. Ele opera como um firewall de aplicativo da Web e possui um balanceador de carga de camada 7 integrado. O Gateway de Aplicativo só dá suporte ao acesso na porta 443 (HTTPS).
- Outra opção para proteger sua rede é o Firewall do Azure. Este componente defende os serviços da Web contra explorações e vulnerabilidades comuns. Ele mantém os aplicativos Oracle altamente disponíveis e ajuda você a atender aos requisitos de conformidade.
- Considere configurar grupos de segurança de rede em um nível de sub-rede para garantir que a rede permita o tráfego apenas em portas e endereços IP específicos.
- Se o aplicativo exigir acesso ao protocolo SSH (Secure Shell) ou RDP (Remote Desktop Protocol), implante um host Azure Bastion como um servidor de salto para fornecer segurança extra para uma postura de segurança madura e aprofundada.
Camadas da Web e do aplicativo
- Implante seu aplicativo em VMs (máquinas virtuais). Agrupe essas VMs em um conjunto de dimensionamento de máquinas virtuais flexível para melhorar a disponibilidade geral.
- Se você precisar que seu aplicativo seja dimensionado automaticamente, considere usar os Conjuntos de Dimensionamento de Máquinas Virtuais do Azure.
- Coloque as VMs em uma única zona de disponibilidade para aproximá-las fisicamente. No entanto, lembre-se de que, à medida que o volume do Azure cresce, uma única zona de disponibilidade pode abranger vários datacenters físicos. A distância entre datacenters físicos pode causar latência de rede que afeta seu aplicativo. Para aproximar as VMs o máximo possível e obter a menor latência possível, implante-as em um grupo de posicionamento por proximidade.
Camada de banco de dados
- Considere implantar a camada de banco de dados como um servidor principal replicado para um servidor secundário usando o Oracle Data Guard.
- Se você usar duas zonas para implantar os servidores primário e secundário em uma região, considere usar a configuração de replicação síncrona do Data Guard depois de verificar a latência de rede entre as zonas na região.
- Se você implantar os servidores primário e secundário em duas regiões, considere usar a configuração de replicação assíncrona do Data Guard.
- Se você precisar de uma estratégia de replicação sem perda de dados, considere usar a configuração de replicação assíncrona.
- Além do Data Guard, outras opções de integração incluem Striim, Qlik, GoldenGate ou Active Data Guard.
Backup e proteção de dados
- Considere usar o Backup do Azure para fazer backup de suas VMs de aplicativo e banco de dados.
- Considere colocar seus backups em uma região diferente da região principal para fornecer proteção extra contra falhas regionais.
- Considere fazer backup do banco de dados usando componentes de armazenamento que tenham recursos de replicação internos.
Recuperação de desastre
- Crie uma arquitetura confiável como estes exemplos:
- Considere usar soluções internas de recuperação de desastre do Azure, como o Azure Site Recovery.