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 que você possa 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 na 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 os dois níveis 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 capacidades que podem levar a uma solução de desempenho, confiável, segura e altamente disponível.
Para obter orientações 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 logon único (SSO) usando a ID do Microsoft Entra. Os clientes podem usar o SSO para se conectar a aplicativos Oracle por meio do navegador da Internet. Para obter mais informações, consulte Habilitar SSO para um aplicativo corporativo.
- Considere usar uma conexão privada com a instalação na nuvem. O Azure fornece recursos de conectividade privada, como conexões de Rota Expressa do Azure e conexões VPN site a site.
- Se um cliente acessar o aplicativo pela Internet, considere um gateway de aplicativo. O Azure Application Gateway fornece duas funcionalidades internas. Ele opera como um firewall de aplicativo da Web e tem um balanceador de carga de Camada 7 integrado. O Application Gateway só suporta acesso na porta 443 (HTTPS).
- Outra opção para proteger sua rede é o Firewall do Azure. Este componente defende os serviços Web contra exploits e vulnerabilidades comuns. Ele mantém os aplicativos Oracle altamente disponíveis e ajuda você a atender aos requisitos de conformidade.
- Considere a configuração de 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 seu aplicativo exigir o protocolo Secure Shell (SSH) ou o acesso RDP (Remote Desktop Protocol), implante um host do Azure Bastion como um servidor de salto para fornecer segurança extra para uma postura de segurança profunda e madura.
Camadas da Web e de aplicativos
- Implante seu aplicativo em máquinas virtuais (VMs). Agrupe essas VMs em um conjunto de escala de máquina virtual flexível para melhorar a disponibilidade geral.
- Se você precisar que seu aplicativo seja dimensionado automaticamente, considere usar os Conjuntos de Dimensionamento de Máquina Virtual do Azure.
- Coloque as VMs em uma única zona de disponibilidade para aproximá-las fisicamente. No entanto, lembre-se de que, à medida que a pegada 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 obter VMs o mais próximo possível e obter a menor latência possível, implante-as em um grupo de posicionamento de proximidade.
Camada de base de dados
- Considere implantar a camada de banco de dados como um servidor primário 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 da 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 o uso da configuração de replicação assíncrona.
- Além do Data Guard, outras opções de integração incluem Striim, Qlik, GoldenGate ou Ative Data Guard.
Cópia de segurança 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 com recursos internos de replicação.
Recuperação após desastre
- Crie uma arquitetura confiável como estes exemplos:
- Considere usar soluções internas de recuperação de desastres do Azure, como o Azure Site Recovery.