Arquiteturas para aplicativos Oracle com banco de dados em Máquinas Virtuais do Microsoft Azure
Este artigo fornece uma arquitetura de referência para implantar o aplicativo Oracle na IaaS do Azure em que o banco de dados da Oracle também reside ou está localizado.
As cargas de trabalho Oracle incluem, além de bancos de dados Oracle, aplicativos próprios da Oracle, como Siebel, PeopleSoft, JD Edwards, E-Business Suite ou aplicativos personalizados do servidor WebLogic. Implantar aplicativos Oracle na Infraestrutura como Serviço (IaaS) do Azure é um cenário comum para organizações que procuram usar a nuvem em suas cargas de trabalho Oracle junto com o banco de dados Oracle. A Microsoft oferece arquiteturas de referência e práticas recomendadas para facilitar esse processo.
Diretrizes gerais de migração de aplicativos
À medida que os aplicativos Oracle são migrados para a IaaS do Azure, há considerações gerais de design que devem ser seguidas independentemente do tipo dos aplicativos. Algumas considerações são específicas aos aplicativos. Nesta seção, listamos as considerações comuns de design de todos os aplicativos, além das considerações específicas de cada aplicativo.
Rede e segurança
As configurações de rede fornecidas para os Aplicativos Oracle no Azure abrangem vários aspectos das considerações de rede e segurança. Aqui está um detalhamento das configurações de rede recomendadas:
Logon único (SSO) com o Microsoft Entra ID e a SAML: use o Microsoft Entra ID para logon único (SSO) usando o protocolo SAML (Security Assertions Markup Language). Esse SSO permite que os usuários se autentiquem uma vez e acessem vários serviços diretamente.
Proxy de aplicativo do Microsoft Entra: considere usar o proxy de aplicativo do Microsoft Entra, principalmente para usuários remotos. Esse proxy permite que você acesse com segurança os aplicativos locais de fora da sua rede.
Roteamento de usuários internos por meio do ExpressRoute: para usuários internos, roteie o tráfego por meio do Azure ExpressRoute para obter uma conexão dedicada e privada nos serviços do Azure, garantindo a baixa latência e a comunicação segura.
Firewall do Azure: se quiser aumentar a segurança, você pode configurar Firewall do Azure no seu aplicativo. O Firewall do Azure ajuda a proteger seus recursos contra ameaças e acessos não autorizados.
Gateway de Aplicativo para usuários externos: quando usuários externos precisarem acessar seu aplicativo, considere usar o Gateway de Aplicativo do Azure. Ele fornece recursos de Firewall de Aplicativo Web (WAF) para proteger seus aplicativos web e balanceamento de carga na Camada 7 para distribuir o tráfego.
Grupos de Segurança de Rede (NSG): proteja suas sub-redes usando Grupos de Segurança de Rede (NSG). Os NSGs permitem controlar o tráfego de entrada e saída para as interfaces de rede, Máquinas Virtuais e sub-redes definindo regras de segurança.
RBAC (controle de acesso baseado em função): para conceder acesso a indivíduos ou funções específicos, use o RBAC. O RBAC fornece controle de acesso refinado aos recursos do Azure com base em funções e permissões.
Bastion Host para acesso SSH: use um Bastion host como uma jumpbox para aprimorar a segurança do acesso SSH. Um Bastion host atua como um gateway seguro para os administradores acessarem as Máquinas Virtuais na rede virtual. Esse host fornece uma camada adicional de segurança.
Mais considerações:
- Criptografia de dados: verifique se os dados inativos e em trânsito estão criptografados. O Azure fornece ferramentas como o Azure Disk Encryption e o SSL/TLS para essa finalidade.
- Gerenciamento de patch: atualize e corrija regularmente seu ambiente EBS para se proteger contra vulnerabilidades conhecidas.
- Monitoramento e registro em log: implemente o Azure Monitor e o Azure Defender para melhorar a segurança e verificar continuamente seu ambiente em busca de ameaças e anomalias. Configure o registro em log para auditoria e análise forense.
Em resumo, essas configurações de rede e segurança visam fornecer um ambiente robusto e seguro para a hospedagem de aplicativos Oracle na IaaS do Azure. Elas incorporam as práticas recomendadas para autenticação, controle de acesso e segurança de rede, tanto para usuários internos quanto externos. Essas configurações também consideram a necessidade de acesso SSH aos servidores de aplicativos. Essas recomendações podem ajudá-lo a configurar uma postura de segurança madura para sua implantação de aplicativos Oracle na IaaS do Azure.
Camada da web: a carga da camada da web equilibra as solicitações e as envia de acordo com a camada de aplicativo, a camada de banco de dados e/ou backup.
Camada de aplicativo: a camada de aplicativo normalmente envolve servidores de aplicativos e sistemas de arquivos compartilhados.
Para dimensionamento automático, os Conjuntos de Dimensionamento de Máquinas Virtuais podem ser uma ótima opção para expandir várias Máquinas Virtuais com base na demanda com regras de escalonamento personalizadas para se adaptarem à carga de trabalho.
Colabore com SMEs (Especialistas no Assunto) do Azure para executar uma avaliação completa da sua arquitetura. Eles podem ajudá-lo a determinar os serviços do Azure mais adequados com base em seus requisitos específicos, incluindo desempenho, disponibilidade e escalabilidade. Lembre-se de considerar fatores como custo, segurança de dados, conformidade e recuperação de desastre ao projetar sua arquitetura.
Também é fundamental verificar e otimizar seus recursos do Azure continuamente para garantir a eficiência e o custo-benefício.
Balanceamento de carga e taxa de transferência: é importante avaliar as características da carga de trabalho dos servidores de aplicativos. Alguns servidores lidam com mais tarefas e criam uma taxa de transferência maior do que outros. Essas informações são cruciais ao projetar os Conjuntos de Dimensionamento de Máquinas Virtuais do Azure e a configuração do balanceamento de carga para garantir que os recursos sejam alocados de forma eficaz
Camada de banco de dados: as arquiteturas de alta disponibilidade (HA) são recomendadas com o Oracle Data Guard para Oracle na IaaS do Azure. Os aplicativos exigem um tipo específico de configuração de HA e estão listados em cada aplicativo.
Backup – os backups são enviados da camada de aplicativo e da camada de banco de dados. É apenas uma das muitas razões pelas quais essas duas camadas não devem ser separadas em dois fornecedores diferentes. Os backups do banco de dados são executados pelo Instantâneo de Volume do Backup do Azure em Arquivos Premium para a região secundária.
Recuperação de Desastre – existem soluções diferentes disponíveis para você escolher. Depende muito das suas necessidades. A arquitetura foi criada para ser altamente disponível. Para replicar a camada de aplicativo, você pode usar o Azure Site Recovery. Outra solução que você pode escolher são as Opções de redundância para discos gerenciados. Ambas as soluções replicam seus dados. As opções de redundância para discos gerenciados são uma solução que pode simplificar a arquitetura, mas também apresentam algumas limitações.
Siebel no Azure
O Oracle Siebel CRM continua sendo uma solução de CRM de nível empresarial favorita de muitas empresas. É um dos aplicativos mais complexos no portfólio da Oracle que oferece uma combinação de recursos transacionais, analíticos e de compromissos para gerenciar operações voltadas para o cliente.
Aqui está a arquitetura recomendada de uma implantação de aplicativo Siebel em Máquinas Virtuais do Azure para o Innovation Pack 16 e anteriores:
O diagrama a seguir é a arquitetura de uma implantação de aplicativo Siebel em Máquinas Virtuais do Azure para o Innovation Pack 17 e anteriores:
Considerações sobre o design do Oracle Siebel
Rede e Segurança: Além disso, as configurações de rede do Oracle Siebel no Azure precisam seguir as considerações gerais de rede e segurança.
A migração deve ser feita usando a sub-rede Siebel Tool.
Camada de Aplicativo
- Versão 17 ou superior – é necessário configurar determinados servidores e utilitários no aplicativo e no banco de dados.
Camada de Banco de Dados
- Garanta que as versões do Banco de Dados e do Siebel sejam compatíveis.
- Garanta que os bancos de dados primários e replicados sejam copiados para um banco de dados secundário usando a arquitetura de referência Oracle do Oracle Data Guard.
E-Business Suite no Azure
O EBS (Oracle E-Business Suite) é um conjunto de aplicativos que inclui SCM (gerenciamento da cadeia de fornecedores) e CRM (gerenciamento de relacionamento com o cliente). O EBS geralmente tem muitas interfaces para sistemas de terceiros, por ser um sistema SCM e CRM. A arquitetura a seguir foi criada para ser altamente disponível em uma região.
No diagrama a seguir, presumimos que os usuários externos não cruzam a rede corporativa.
Considerações sobre o design do Oracle EBS
Camada de banco de dados – banco de dados primário e secundário deve estar dentro de um datacenter. A configuração síncrona deve ser usada. Se você instalar seu aplicativo em vários datacenters, deverá configurar o Data Guard no modo Assíncrono.
JD Edwards no Azure
O JD Edwards da Oracle é um conjunto de aplicativos integrados composto por uma ampla gama de programas de software de planejamento de recursos empresariais. Atualmente, o JD Edwards é usado em cadeia de suprimentos, gerenciamento de armazéns, logística, planejamento de recursos de fabricação e muito mais. Devido ao uso do aplicativo, vemos que as interfaces para outros sistemas também são importantes.
A arquitetura a seguir foi criada para ser altamente disponível. Presumimos que os usuários externos não estão acessando a rede corporativa. Se um usuário externo acessar o aplicativo usando a rede corporativa, a arquitetura poderá ser simplificada na rede da seguinte forma.
Considerações sobre design do JD Edwards
Camada da web: a camada web do aplicativo normalmente consiste em vários servidores de aplicativos. No JD Edwards, as regras geralmente são salvas nesses servidores web de aplicativos.
Camada de apresentação: cada instância na camada de apresentação está associada ao armazenamento. Cortar dependências entre instâncias pode levar a altas latências, portanto, é crucial avaliá-las com cuidado.
Variação de desempenho do servidor: alguns servidores podem lidar com mais tarefas e criar uma taxa de transferência maior do que outros. Durante a fase de design, é fundamental avaliar essa variação de taxa de transferência para garantir que sua infraestrutura possa lidar com cargas de trabalho de pico com eficiência.
Rearquitetura: o uso dos Conjuntos de Dimensionamento de Máquinas Virtuais do Azure para dimensionamento automático não requer uma rearquitetura da configuração do JD Edwards. É uma solução escalonável que pode ser implementada sem alterações significativas na arquitetura do aplicativo.
Camada de Banco de Dados – a primária e a secundária ficam dentro de um datacenter e a configuração síncrona deve ser usada. Se você instalar seu aplicativo em vários datacenters, deverá configurar o Data Guard no modo Assíncrono. Os dados da camada de banco de dados são enviados diretamente para um Armazenamento do Azure. O armazenamento é dependente da configuração atual de sua arquitetura.
PeopleSoft no Azure
O conjunto de aplicativos PeopleSoft da Oracle contém programas de software de gerenciamento de recursos humanos e finanças. O conjunto de aplicativos é multicamadas e os aplicativos incluem: HRMS (sistemas de gerenciamento de recursos humanos), CRM (gerenciamento de relacionamento com o cliente), FSCM (gerenciamento da cadeia de fornecedores e finanças) e EPM (gerenciamento de desempenho empresarial).
Considerações sobre o design do PeopleSoft
Camada de aplicativo: a camada de aplicativo contém várias tarefas e servidores. Ela executa a lógica de negócios e os processos, mas também mantém a conexão com o banco de dados. Assim que essa dependência é cortada, causa latências.
Dependência entre as camadas de aplicativo e o banco de dados: é importante minimizar a latência entre as camadas de aplicativo e de banco de dados. Ao colocar a camada de banco de dados e de aplicativo no mesmo provedor de nuvem (Azure, nesse caso), você reduz a latência da rede. O Azure fornece várias opções de rede e serviços como emparelhamento da VNet (rede virtua) ou o ExpressRoute para garantir conexões de baixa latência entre as camadas.
Considerações sobre o sistema operacional: se o Agendador de Processos exigir especificamente sistemas operacionais Windows, você ainda poderá executá-lo em Máquinas Virtuais do Azure. O Azure é compatível com várias versões do Windows Server, permitindo que você escolha aquela que atenda aos requisitos do seu aplicativo.
Avaliação da arquitetura: avalie cuidadosamente seus requisitos de arquitetura, incluindo escalabilidade, disponibilidade e desempenho. Para garantir alta disponibilidade e escalabilidade, considere configurar várias instâncias do servidor de aplicativos em uma configuração com balanceamento de carga.
Camada de banco de dados – o primário e replicado para um secundário deve permanecer dentro de um datacenter. A configuração síncrona deve ser usada. Se você instalar seu aplicativo em vários datacenters, deverá configurar o Data Guard no modo Assíncrono.
Próximas Etapas
Arquiteturas de referência para o Oracle Database
Migrar a carga de trabalho da Oracle para Máquinas Virtuais do Azure