Saiba mais sobre a Implantação do JD Edwards EnterpriseOne no Oracle Cloud Infrastructure

Se quiser provisionar o JD Edwards EnterpriseOne no Oracle Cloud Infrastructure ou migrar ambientes do JD Edwards EnterpriseOne do seu data center para o Oracle Cloud Infrastructure, você poderá planejar uma topologia multihost, segura e de alta disponibilidade.

Antes de Começar

O Oracle Cloud Infrastructure suporta o aplicativo JD Edwards EnterpriseOne release 9.0, 9.1 e 9.2. Antes de começar a planejar implantar ou migrar seu aplicativo JD Edwards EnterpriseOne, identifique se o Oracle Cloud Infrastructure suporta a combinação de versão do aplicativo JD Edwards EnterpriseOne, versão das ferramentas JD Edwards EnterpriseOne e o sistema operacional no qual você deseja executar seus aplicativos.

• Aplicativo JD Edwards EnterpriseOne versão 9.2 com o JD Edwards EnterpriseOne Tools versão 9.2. x. Ele suporta a instalação manual e automatizada de componentes do JD Edwards EnterpriseOne em sistemas operacionais Oracle Linux e Windows.

• Aplicativo JD Edwards EnterpriseOne versão 9.1 com o JD Edwards EnterpriseOne Tools versão 9.1. x ou 9.2. x. Ele suporta apenas a instalação manual de componentes do JD Edwards EnterpriseOne em sistemas operacionais Oracle Linux e Windows.

Para obter informações sobre versões anteriores do aplicativo JD Edwards EnterpriseOne, entre em contato com o Oracle Advanced Consulting Services.

Consulte o My Oracle Support para obter informações sobre as certificações definitivas.

Considerações para Implantação no Oracle Cloud Infrastructure

A Oracle recomenda a criação de sub-redes separadas para suas instâncias, como host bastion, banco de dados, aplicativo e instâncias do balanceador de carga, para garantir que os requisitos de segurança apropriados possam ser implementados nas diferentes sub-redes.

Sub-redes Privadas ou Públicas

Você pode criar instâncias em uma sub-rede privada ou pública com base no fato de desejar permitir o acesso às instâncias pela Internet. As instâncias criadas em uma sub-rede pública recebem um endereço IP público e você pode acessar essas instâncias pela Internet. Não é possível designar um endereço IP público a instâncias criadas em uma sub-rede privada. Portanto, você não pode acessar essas instâncias pela internet.

A imagem a seguir mostra uma rede virtual na nuvem (VCN) com sub-redes públicas e privadas. A VCN contém dois domínios de disponibilidade e cada domínio de disponibilidade contém uma sub-rede pública e privada. Os servidores Web são colocados na sub-rede pública desta imagem, portanto, as instâncias do servidor Web têm um endereço IP público anexado a ela. Você pode acessar essas instâncias da Oracle Cloud na sub-rede pública pela internet ativando a comunicação por meio do IGW (gateway de internet). Você terá que atualizar a tabela de roteamento para permitir o tráfego de e para o IGW. Para permitir o tráfego para os servidores Web a partir da Internet, você deve criar balanceadores de carga na sub-rede pública. Para acessar suas instâncias pela internet, você também precisa criar um host bastião na sub-rede pública e acessar o host bastião pela IGW.

Os servidores de banco de dados são colocados na sub-rede privada desta imagem. Você pode acessar instâncias da Oracle Cloud na sub-rede privada de seus data centers conectando-se por meio do gateway de roteamento dinâmico (DRG). O DRG conecta suas redes locais à sua rede na nuvem. Para ativar a comunicação entre o DRG e o equipamento local do cliente, use o IPSec VPN ou o Oracle Cloud Infrastructure FastConnect. Você também precisará atualizar a tabela de roteamento para permitir o tráfego de e para a DRG.

Descrição da ilustração public_private_subnets_jde.png

Cenário 1: Implantar Todas as Instâncias em Sub-redes Privadas

A Oracle recomenda implantar todas as instâncias em sub-redes privadas para ambientes de produção onde não há pontos finais voltados para a Internet. Esse tipo de implantação é útil quando você deseja ter uma implantação híbrida com a nuvem como uma extensão para seus data centers existentes.

Nesta implantação, todas as instâncias, incluindo servidores de aplicativos e bancos de dados, são implantadas em uma sub-rede privada. Um endereço IP público não pode ser designado a instâncias criadas em uma sub-rede privada; portanto, você não pode acessar essas instâncias pela internet. Para acessar seus servidores de aplicativos do seu ambiente local nesta configuração, você pode:

• Configure um túnel IPSec VPN entre seu data center e o Oracle Cloud Infrastructure DRG antes de provisionar os servidores de aplicativos.

• Crie um host bastion nesta configuração e acesse todos os servidores na sub-rede privada a partir do host bastion.

Cenário 2: Implantar Instâncias em Sub-redes Pública e Privada

Você pode implantar algumas instâncias em uma sub-rede pública e algumas instâncias em uma sub-rede privada. Esse tipo de implantação é útil quando a implantação inclui endpoints voltados para a Internet e não voltados para a Internet.

Nessa configuração, algumas instâncias da aplicação são colocadas em uma sub-rede pública e outras em uma sub-rede privada. Por exemplo, você pode ter instâncias da aplicação que atendem usuários internos e outro conjunto de instâncias da aplicação que atendem usuários externos. Nesse cenário, coloque as instâncias do aplicativo que atendem ao tráfego interno em uma sub-rede privada e coloque os servidores de aplicativos que atendem ao tráfego externo em uma sub-rede pública. Você também pode configurar um balanceador de carga público nas instâncias da aplicação voltadas para a Internet, em vez de colocar os servidores de aplicações que atendem ao tráfego externo em uma sub-rede pública. Se você colocar o bastion host em uma sub-rede pública, o bastion host receberá um endereço IP público e você poderá acessá-lo pela Internet. Você pode acessar suas instâncias na sub-rede privada por meio do servidor bastion.

Cenário 3: Implantar Todas as Instâncias em Sub-redes Públicas

A Oracle recomenda essa implantação para demonstrações rápidas ou para implantações de nível de produção sem pontos finais internos. Essa implantação só é adequada se você não tiver seu próprio data center ou não puder acessar instâncias por VPN e quiser acessar a infraestrutura pela Internet.

Nesta implantação, todas as instâncias, incluindo a aplicação e as instâncias do banco de dados, são implantadas em sub-redes públicas.

Cada instância da sub-rede pública tem um endereço IP público anexado a ela. Embora instâncias com endereços IP públicos possam ser acessadas pela internet, você pode restringir o acesso usando listas de segurança e regras de segurança. Para executar tarefas de administração, a Oracle recomenda que você coloque um host bastião nesta configuração. Nesse cenário, você não abriria portas de administração para a internet pública, mas abriria as portas de administração apenas para o host bastião e configuraria listas de segurança e regras de segurança para garantir que a instância só possa ser acessada a partir do host bastião.

Anti-Afinidade

Ao criar várias instâncias para alta disponibilidade em um domínio de disponibilidade no Oracle Cloud Infrastructure, a antiafinidade das instâncias pode ser obtida usando domínios de falha.

Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade contém três domínios de falha. Os domínios de falha permitem distribuir suas instâncias de forma que elas não fiquem no mesmo hardware físico de um único domínio de disponibilidade. Portanto, uma falha de hardware ou manutenção de hardware do Oracle Compute que afete um domínio de falha não afeta instâncias em outros domínios de falha. Usando domínios de falha, você pode proteger suas instâncias contra falhas de hardware inesperadas e interrupções planejadas.

Para alta disponibilidade de bancos de dados, você pode criar sistemas de banco de dados Oracle Real Application Clusters (Oracle RAC) de 2 nós. Os dois nós do Oracle RAC são sempre criados em domínios de falha separados por padrão. Portanto, os nós do banco de dados não estão no mesmo host físico nem no mesmo rack físico. Isso protege as instâncias do banco de dados contra o host físico subjacente e a parte superior das falhas do switch de rack.

Arquitetura para Implantar o JD Edwards EnterpriseOne em uma Única Região

Você pode implantar o JD Edwards EnterpriseOne em um único domínio de disponibilidade, garantindo alta disponibilidade.

Você pode obter alta disponibilidade colocando as instâncias do aplicativo dentro de vários domínios de falha. Use essa arquitetura quando quiser garantir que sua aplicação esteja disponível mesmo quando uma instância da aplicação for desativada em um domínio de falha. As outras instâncias do aplicativo disponíveis dentro do outro domínio de falha continuam a processar as solicitações. Você pode implantar o JD Edwards EnterpriseOne manualmente ou usando as ferramentas de automação do JD Edwards EnterpriseOne no Oracle Cloud Infrastructure.

Esta arquitetura mostra que instâncias redundantes são implantadas na camada de apresentação e na camada intermediária em um domínio de disponibilidade para garantir alta disponibilidade dentro do domínio de disponibilidade. Todas as instâncias no domínio de disponibilidade estão ativas. Essa alta disponibilidade de uma aplicação em um domínio de disponibilidade pode ser obtida colocando instâncias da aplicação em domínios de falha separados. Os domínios de falha permitem distribuir suas instâncias de forma que elas não fiquem no mesmo hardware físico de um único domínio de disponibilidade. Uma falha de hardware ou manutenção de hardware do Oracle Cloud Infrastructure Compute que afeta um domínio de falha não afeta instâncias em outros domínios de falha. Se uma instância falhar, o tráfego será desviado para outras instâncias no domínio de disponibilidade que continuam a processar as solicitações. No entanto, se sua conexão com o domínio de disponibilidade falhar ou todo o domínio de disponibilidade for desativado, as instâncias não estarão disponíveis para processar as solicitações.

As instâncias da sub-rede privada exigem conexão de saída com a Internet para fazer download de patches, bem como para aplicar atualizações do sistema operacional e do aplicativo. Para isso, use um gateway NAT (Network Address Translation) na sua VCN. Com um gateway NAT, os hosts na sub-rede privada podem iniciar conexões com a Internet e receber respostas, mas não receberão conexões de entrada iniciadas pela Internet.

A Oracle recomenda que o banco de dados e os aplicativos implantados no Oracle Cloud Infrastructure tenham um backup robusto da estratégia de recuperação. É recomendável armazenar o backup de bancos de dados e instâncias da aplicação no Oracle Cloud Infrastructure Object Storage. É possível fazer backup dos bancos de dados e instâncias da aplicação em sub-redes privadas na Oracle Cloud Infrastructure Object Storage usando um gateway de serviço. Um gateway de serviço fornece acesso ao Oracle Cloud Infrastructure Object Storage sem passar pela Internet.

Os backups automáticos e sob demanda do banco de dados para o Oracle Cloud Infrastructure Object Storage podem ser configurados usando a console do Oracle Cloud Infrastructure. Isso requer conectividade com o Oracle Cloud Infrastructure Object Storage usando um ponto final Swift. Todos os backups do banco de dados no Oracle Cloud Infrastructure Object Storage são criptografados com a mesma chave mestra usada para criptografia de wallet TDE (Transparent Data Encryption). O serviço de backup automático de banco de dados usa estratégia de backup incremental semanal para fazer backup de bancos de dados com uma política de retenção de 30 dias. Também é possível realizar um backup completo sob demanda de bancos de dados para requisitos ad-hoc.

O backup do aplicativo pode ser configurado usando o recurso de backup baseado em política do Oracle Cloud Infrastructure Block Volumes. O Oracle Cloud Infrastructure Block Volumes fornece a você a capacidade de executar backups de volume automaticamente com base em uma programação e retê-los com base na política de backup selecionada. Isso permite que você cumpra seus requisitos regulamentares e de conformidade de dados. Existem três políticas de backup predefinidas: Bronze, Prata e Ouro. Cada política de backup tem uma frequência de backup e um período de retenção predefinidos.

A arquitetura consiste em uma rede virtual na nuvem (VCN) com o host bastion, a camada do balanceador de carga, a camada de apresentação, a camada intermediária, a camada de administração e a camada do banco de dados. As camadas são colocadas em uma única sub-rede da VCN em um único domínio de disponibilidade.

No diagrama de arquitetura a seguir, o host bastion é implantado em uma sub-rede pública e todas as outras instâncias são colocadas em sub-redes privadas. Dependendo dos seus requisitos de negócios, você pode colocar instâncias em sub-redes públicas ou privadas. Você pode acessar as instâncias que estão em sub-redes privadas pela porta 22 por meio do host bastion ou do gateway de roteamento dinâmico (DRG). Para ativar a comunicação entre o DRG e o equipamento local do cliente, use o IPSec VPN ou o Oracle Cloud Infrastructure FastConnect.

O Gerenciador de Servidores na camada Administração se comunica com a camada Apresentação, a camada Intermediária e a camada Banco de Dados para fornecer implantação de código, gerenciamento de configuração, acesso às métricas de runtime e acesso ao log. O Servidor de Implantação na camada Administração se comunica com a camada Intermediária e a camada Banco de Dados para criar e implantar o código. O Cliente de Desenvolvimento se comunica com a camada Intermediária e a camada Banco de Dados. O ADF (Application Development Framework) e o Oracle Business Intelligence Publisher se comunicam com o servidor HTML na camada de Apresentação.

Descrição da ilustração single_availability_domain_jd_edwards_deployment.png

Esta arquitetura é dividida nas seguintes camadas:

• Host Bastion: O host bastion é um componente opcional que pode ser usado como um servidor jump para acessar instâncias na sub-rede privada. Um bastion host é uma instância do Oracle Cloud Infrastructure Compute que usa o Linux como seu sistema operacional. Coloque o bastião host em uma sub-rede pública e designe-lhe um endereço IP público para acessá-lo pela Internet.

  Para fornecer um nível adicional de segurança, você pode configurar listas de segurança para acessar o bastion host somente a partir do endereço IP público da sua rede local. Você pode acessar instâncias do Oracle Cloud Infrastructure na sub-rede privada por meio do host bastion. Para fazer isso, ative o encaminhamento ssh-agent, que permite que você se conecte ao bastion host e acesse o próximo servidor encaminhando as credenciais do seu computador. Você também pode acessar as instâncias na sub-rede privada usando o túnel SSH dinâmico. O túnel SSH é uma maneira de acessar uma aplicação Web ou outro serviço de listening. O túnel dinâmico fornece um proxy SOCKS na porta local, mas as conexões são originadas do host remoto.

• Camada do Balanceador de Carga: A camada do balanceador de carga contém as instâncias do Oracle Cloud Infrastructure Load Balancing que balanceam o tráfego para todas as instâncias na camada de apresentação. O balanceador de carga recebe solicitações de usuários e, em seguida, roteia essas solicitações para instâncias na camada de apresentação.

  Use o Oracle Cloud Infrastructure Load Balancing para distribuir tráfego para as instâncias da aplicação dentro de um VCN. Este serviço fornece uma instância principal e stand-by do balanceador de carga para garantir que, se o balanceador de carga principal ficar indisponível, o balanceador de carga stand-by encaminhará as solicitações. O balanceador de carga garante que as solicitações sejam roteadas para as instâncias do aplicativo íntegras. Se ocorrer um problema em uma instância do aplicativo, o balanceador de carga roteará as solicitações para as instâncias do aplicativo íntegras restantes.

  Com base nas suas necessidades, você pode colocar balanceadores de carga em uma sub-rede pública ou privada.

  • Para pontos finais internos, que não são acessíveis pela Internet, use um balanceador de carga privado. Um balanceador de carga privado tem um endereço IP privado e não é acessível pela Internet. As instâncias principal e stand-by de um balanceador de carga residem na mesma sub-rede privada. Você pode acessar balanceadores de carga privados no VCN ou no seu data center pela IPSec VPN por meio de um DRG. O balanceador de carga privado aceita tráfego do seu data center e distribui o tráfego para as instâncias do aplicativo subjacente.

  • Para pontos finais voltados para a Internet, use um balanceador de carga público. Um balanceador de carga público tem um endereço IP público e pode ser acessado pela Internet. Você pode acessar os balanceadores de carga públicos pela Internet por meio do gateway da Internet.

  • Para acessar pontos finais internos e pontos finais voltados para a Internet, configure balanceadores de carga privados e balanceadores de carga públicos. Configure balanceadores de carga privados para atender ao tráfego interno e configure balanceadores de carga públicos para atender ao tráfego da Internet.

  Registre o endereço IP público ou privado das instâncias do Oracle Cloud Infrastructure Load Balancing no seu servidor de nome de domínio local ou público (DNS) para resolução de domínio do ponto final da aplicação.

  As portas fornecidas no diagrama de arquitetura são apenas um exemplo. Você pode usar qualquer porta que esteja disponível.

• Camada de administração: A camada de administração contém uma única instância dos seguintes servidores. Você não precisa de uma instância redundante desses servidores para garantir alta disponibilidade.

  • Servidor de provisionamento: use este servidor para automatizar a implantação completa dos componentes do JD Edwards EnterpriseOne no Oracle Cloud Infrastructure. Ele se comunica com todas as instâncias nas outras camadas, incluindo as instâncias na camada do banco de dados, na porta 22. Ele hospeda a Console de Provisionamento de Um Clique do JD Edwards EnterpriseOne e a Console do JD Edwards EnterpriseOne Server Manager.

  • Servidor de Implantação: Durante o processo de instalação, este servidor atua como o repositório central de todos os arquivos e pacotes de instalação necessários. O software é distribuído ou implantado para todos os outros servidores e clientes deste servidor.

  • Cliente de desenvolvimento: O cliente do JD Edwards EnterpriseOne Development contém componentes executados como aplicativos Microsoft Windows padrão (por exemplo, Console Ativo, FDA (Forms Design Aid) e RDA (Report Design Aid)) e componentes executados em um web browser.

  • Servidor ADF (Application Development Framework): O servidor ADF do JD Edwards EnterpriseOne é uma aplicação Web implantada em um servidor Oracle WebLogic com runtime ADF. Ele é usado para executar aplicativos JD Edwards EnterpriseOne desenvolvidos com o Oracle ADF.

  • Oracle Business Intelligence Publisher: O Oracle Business Intelligence Publisher apresenta os dados coletados pelo JD Edwards EnterpriseOne na forma de relatórios. Use o Oracle Business Intelligence Publisher para apresentar relatórios usando modelos diferentes com base nos requisitos de negócios. Você pode projetar e controlar como as saídas de relatório são apresentadas usando arquivos de modelo.

• Camada de apresentação: A camada de apresentação contém instâncias redundantes de Serviços de Interface de Aplicativo e Servidores de Aplicativos Java para fornecer alta disponibilidade. Esses servidores se comunicam com servidores na camada intermediária. Todas as instâncias estão ativas e recebem tráfego do balanceador de carga. Cada instância está associada a um volume de armazenamento em blocos. Essa camada também contém componentes que podem ser usados para criar integração entre o JD Edwards EnterpriseOne e um sistema externo. Sua implementação pode incluir um ou mais desses componentes.

  Esta camada contém os seguintes servidores:

  • Servidor AIS (Application Interface Services): O servidor do Application Interface Service fornece a interface de comunicação entre as aplicações empresariais móveis do JD Edwards EnterpriseOne e o JD Edwards EnterpriseOne.

  • Servidores de Aplicativos Java Padrão (JAS Padrão): Ele recebe solicitações do balanceador de carga e executa lógica de negócios simples. Para tarefas que requerem lógica de negócios complicada, o JAS Padrão passa as solicitações para o servidor lógico. Ele também transmite solicitações para o servidor AIS em alguns casos. No entanto, ele não está configurado com o servidor AIS para o runtime AIS.

  • Servidores de Aplicativos Java Dedicados (JAS Dedicado): Ele recebe solicitações do Servidor AIS. Ele transmite solicitações ao servidor lógico para executar tarefas que exigem lógica de negócios complicada. Ele é configurado com o servidor AIS para o runtime do AIS.

  Para garantir alta disponibilidade em um domínio de disponibilidade, implante instâncias redundantes de cada componente. Todas as instâncias estão ativas e recebem tráfego do balanceador de carga e da camada intermediária.

• Camada Intermediária: A camada intermediária contém servidores lógicos e servidores batch. Eles não são balanceados de carga diretamente, mas têm mapeamento individual com servidores na camada de apresentação. Você pode hospedar o servidor lógico e o servidor batch na mesma instância do servidor enterprise. No entanto, é recomendável configurar o servidor lógico e o servidor batch em instâncias separadas do servidor enterprise.

  A camada intermediária recebe solicitações da camada de apresentação. Depois de processar as solicitações, ele encaminha as solicitações para os servidores de banco de dados. Todas as instâncias dos servidores estão ativas e processam solicitações.

  Esta camada contém os seguintes servidores:

  • Servidores lógicos ou servidores empresariais: Esses servidores contêm a lógica de negócios ou funções de negócios.

  • Servidores batch: Esses servidores são usados para processamento batch.

• Camada de banco de dados: A camada de banco de dados contém instâncias do servidor de banco de dados JD Edwards EnterpriseOne. Para requisitos de alta disponibilidade, a Oracle recomenda que você use sistemas de banco de dados Oracle Real Application Clusters (Oracle RAC) de dois nós ou um sistema Oracle Database Exadata Cloud Service no Oracle Cloud Infrastructure para configurar instâncias do servidor de banco de dados JD Edwards EnterpriseOne.

  Você pode configurar instâncias de banco de dados redundantes para fornecer alta disponibilidade. Para sistemas de banco de dados Oracle RAC e Oracle Database Exadata Cloud Service, as solicitações recebidas da sub-rede de aplicativos são balanceadas de carga entre os servidores de banco de dados. Se uma instância de banco de dados ficar indisponível, a outra instância de banco de dados processará as solicitações. Você pode usar o Oracle Cloud Infrastructure Object Storage para fazer backup do banco de dados JD Edwards EnterpriseOne usando o Oracle Recovery Manager (RMAN). Para fazer backup ou patch do banco de dados JD Edwards EnterpriseOne para o Oracle Cloud Infrastructure Object Storage, o VCN do sistema de BD deve ser configurado com um gateway de serviço ou com um gateway de Internet. É recomendável usar um gateway de serviço em vez de um gateway de Internet para backup e aplicação de patches.

  Use listas de segurança para restringir o acesso aos servidores de banco de dados somente do bastion host, da camada de aplicativos e dos servidores locais. Você pode configurar listas de segurança para garantir que a comunicação ocorra somente pela porta 22, pelo host bastião e pela porta 1521. Além disso, certifique-se de que os sistemas de banco de dados não possam ser acessados pela Internet.

Você pode usar o Oracle Cloud Infrastructure Object Storage para fazer backup das instâncias na camada de apresentação e na camada intermediária.

Arquitetura para Implantar o JD Edwards EnterpriseOne com Recuperação de Desastres

Esta arquitetura mostra a implantação de servidores de aplicativos JD Edwards EnterpriseOne com recuperação de desastres. Mostra uma VCN com o bastião em uma sub-rede pública e todos os outros servidores em uma sub-rede privada.

Os servidores de produção são colocados em duas regiões diferentes. Os servidores em uma região estão no modo ativo e os servidores na segunda região (região Recuperação de Desastres) estão no modo stand-by.

No diagrama de arquitetura, o host bastion é implantado em uma sub-rede pública e todas as outras instâncias são implantadas em sub-redes privadas. Você pode colocar as instâncias em sub-redes públicas ou privadas com base em seus requisitos de negócios. Você pode acessar as instâncias em sub-redes privadas pela porta 22 por meio do host bastion ou da DRG. Para ativar a comunicação entre o DRG e o equipamento de pré-emissões do cliente, use o IPSec VPN ou Oracle Cloud Infrastructure FastConnect.

Nesta arquitetura, várias instâncias da aplicação são implantadas em vários domínios de falha para garantir alta disponibilidade. Isso garante que seu aplicativo esteja disponível mesmo quando um dos domínios de disponibilidade não estiver disponível. As instâncias do aplicativo disponíveis em outro domínio de disponibilidade continuam a processar as solicitações.

Os anfitriões bastião em ambas as regiões estão ativos e podem atender solicitações SSH para ambas as regiões o tempo todo. O serviço DNS local ou externo recebe solicitação para o aplicativo JD Edwards EnterpriseOne. Essas solicitações são de carga de round-robin balanceada pelo balanceador de carga na região ativa. Em seguida, o balanceador de carga roteia a solicitação para instâncias na camada de apresentação e na camada intermediária. As instâncias na camada intermediária roteiam a solicitação para instâncias de banco de dados ativas para processamento. O cliente de desenvolvimento na camada de administração também se comunica com o banco de dados. O servidor de provisionamento na camada de administração se comunica com instâncias em todas as camadas.

Se a região principal não estiver disponível, você deve alternar manualmente para o servidor de banco de dados em execução na região Recuperação de Desastres e começar a usar o host bastião ou o balanceador de carga em execução na região Recuperação de Desastres.

É possível fazer backup dos bancos de dados e instâncias de aplicativos em sub-redes privadas para o armazenamento de objetos Oracle Cloud Infrastructure usando um gateway de serviço. Um gateway de serviço fornece acesso ao armazenamento de objetos sem passar pela Internet.

Descrição da ilustração jde2.png

• Host Bastion: Um host bastion é um componente opcional que você pode provisionar em cada região para atuar como um host jump para acessar instâncias de aplicativos e bancos de dados. Os hosts Bastion em ambas as regiões estão no estado ativo.

• Instância do balanceador de carga: as instâncias do Oracle Cloud Infrastructure Load Balancing distribuem tráfego pelos servidores de aplicativos. A instância do balanceador de carga na região ativa/principal está ativa. As solicitações recebidas no URL do JD Edwards EnterpriseOne são enviadas ao balanceador de carga na região ativa por um serviço DNS local ou externo.

• Camada de apresentação: A camada de apresentação contém instâncias redundantes do Application Interface Services (AIS) e do Java Application Servers (JAS) para fornecer alta disponibilidade. Esses servidores se comunicam com servidores na camada intermediária. Todas as instâncias estão ativas e recebem tráfego do balanceador de carga. Cada instância está associada a um volume de armazenamento em blocos. Essa camada também contém componentes que podem ser usados para criar integração entre o JD Edwards EnterpriseOne e um sistema externo. Sua implementação pode incluir um ou mais desses componentes.

• Camada Intermediária: A camada intermediária contém servidores lógicos e servidores batch. Eles não são balanceados de carga diretamente, mas têm mapeamento individual com servidores na camada de apresentação.

• Camada de banco de dados: Configure instâncias de banco de dados altamente disponíveis em ambas as regiões. O servidor de banco de dados em execução na região ativa/principal está no estado ativo. Em cada região, pelo menos duas instâncias do banco de dados são configuradas para garantir alta disponibilidade em uma região. Se uma instância do banco de dados não estiver disponível na região ativa/principal, faça switchover para a instância do banco de dados na região Recuperação de Desastres e comece a usar o balanceador de carga na região Recuperação de Desastres para acessar o ambiente.

  Use o Oracle Active Data Guard no modo síncrono para replicar o banco de dados entre regiões.

Sobre Grupos de Segurança de Rede

No Oracle Cloud Infrastructure, as regras de firewall são configuradas por meio de grupos de segurança de rede. Um grupo de segurança de rede separado é criado para cada camada.

Use listas de segurança para permitir o tráfego entre diferentes camadas e entre o host bastião e hosts externos. As regras de segurança contêm regras de entrada e saída para filtrar o tráfego no nível da camada. Eles também contêm informações sobre portas de comunicação através das quais a transferência de dados é permitida. Essas portas (ou, em alguns casos, os protocolos que precisarão de portas abertas nas regras de segurança) são mostrados em cada linha de grupo de segurança de rede nos diagramas de arquitetura.

Cada grupo de segurança de rede é imposto no nível VNIC. A transferência de um pacote de dados é permitida se uma regra em qualquer uma das listas permitir tráfego (ou se o tráfego fizer parte de uma conexão existente que está sendo rastreada). Além do grupo de segurança de rede, use iptables para implementar outra camada de segurança no nível da instância.

Para implantações em uma sub-rede pública, você pode fornecer um nível adicional de segurança impedindo o acesso às instâncias da aplicação e do banco de dados pela Internet. Use um grupo de segurança de rede personalizado para impedir o acesso à aplicação e às instâncias do banco de dados pela Internet e permitir o acesso ao banco de dados e aos hosts da aplicação pela porta 22 a partir do host bastion para fins de administração. Não ative o acesso SSH às instâncias do aplicativo e do banco de dados na Internet, mas você pode permitir o acesso SSH a essas instâncias na sub-rede que contém o host bastion.

Você pode acessar suas instâncias na sub-rede privada por meio do servidor bastion.

Grupo de Segurança de Rede para o Host Bastion

O grupo de segurança de rede bastion permite que o host bastion seja acessível pela Internet pública na porta 22.

• Para permitir o tráfego SSH da rede on-premises para o bastião host pela Internet:

  Entrada com monitoramento de estado: Permitir tráfego TCP do CIDR de origem 0.0.0.0/0 e todas as portas de origem para a porta de destino 22 (SSH).

  Source Type = CIDR, Source CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

  Você também pode restringir o host bastion a ser acessível pela internet na porta 22 somente do seu data center, em vez de da Internet pública (0.0.0.0/0). Para isso, use o IP do roteador de borda em vez do CIDR de origem como 0.0.0.0/0 na regra de entrada com monitoramento de estado.

• Para permitir todo o tráfego do host bastion para o Oracle Cloud Infrastructure:

  Saída com monitoramento de estado: Permitir tráfego TCP para CIDR de destino 0.0.0.0/0 de todas as portas de origem para todas as portas de destino.

  Destination Type = CIDR, Destination CIDR = <CIDR block of VCN>, IP Protocol = TCP, Source Port Range = All, Destination port range = All

Você pode adicionar ou remover regras do grupo de segurança de rede com base em seus requisitos. Além disso, especifique as portas nas quais você deseja acessar os servidores de aplicativos e os servidores de Serviços de Interface de Aplicativos do Java.

Grupo de Segurança de Rede para a Camada de Administração

• Entrada com monitoramento de estado: Permitir tráfego TCP na porta de destino 22 (SSH) do bloco CIDR de origem da VCN e de qualquer porta de origem.

• Entrada com monitoramento de estado: Bloco CIDR de origem do VCN no TCP, porta de origem = todos, porta de destino = 445, 5985, 14501-14510, 3000, 8998–8999, 5150

• Saída com monitoramento de estado: Permite todo o tráfego.

Grupo de Segurança de Rede para o Nível do Balanceador de Carga

A arquitetura contém balanceadores de carga privados, que são colocados em sub-redes privadas. Se você colocar as instâncias do balanceador de carga em uma sub-rede pública, estará permitindo o tráfego da internet para as instâncias do balanceador de carga.

• Entrada com monitoramento de estado: Bloco CIDR de origem do VCN e rede local no TCP, porta de origem = todos, porta de destino = portas nas quais você criou listener nas instâncias do balanceador de carga

• Saída com monitoramento de estado: Permite todo o tráfego.

Grupo de Segurança de Rede para o Nível de Apresentação

• Para permitir o tráfego do ambiente local e da VCN para a sub-rede da camada de apresentação:

  Entrada com monitoramento de estado: Bloco CIDR de origem da rede VCN e local no TCP, porta de origem = todos, porta de destino = 14501–14510, 5150, porta do Weblogic Admin Server, portas do Servidor Web

• Entrada com monitoramento de estado: Bloco CIDR de origem da VCN no TCP, porta de origem = todos, porta de destino = 22 (SSH)

• Para permitir o tráfego da sub-rede da camada de apresentação para a sub-rede da camada intermediária:

  Saída com monitoramento de estado: Origem 0.0.0.0/0 no TCP, porta de origem = todos, porta de destino = todos

Além disso, especifique as portas nas quais você deseja acessar os servidores de Aplicativos e os servidores de Serviços de Interface de Aplicativos do Java e as portas nas quais deseja acessar os servidores do Oracle Business Intelligence Publisher.

Grupo de Segurança de Rede para a Camada Intermediária

• Para permitir o tráfego do ambiente local e da VCN para a sub-rede da camada intermediária:

  Entrada com monitoramento de estado: Bloco CIDR de origem do VCN e rede local no TCP, porta de origem = todos, porta de destino = 6017-6023, 14502-14510, 5150

• Entrada com monitoramento de estado: Bloco CIDR de origem da VCN no TCP, porta de origem = todos, porta de destino = 22 (SSH)

• Para permitir o tráfego da sub-rede da camada intermediária para a sub-rede da camada de apresentação:

  Saída com monitoramento de estado: Origem 0.0.0.0/0 no TCP, porta de origem = todos, porta de destino = todos

Lista de Segurança para a Camada de Banco de Dados

• Para permitir o tráfego do host bastion para a camada do banco de dados:

  Entrada com monitoramento de estado: Bloco CIDR de origem do host bastion no TCP, porta de origem = todos, porta de destino = 22

• Para permitir tráfego da camada intermediária para a camada do banco de dados:

  Entrada com monitoramento de estado: Bloco CIDR de origem das camadas intermediárias no TCP, porta de origem = todos, porta de destino = 1521

• Para permitir o tráfego do ambiente local e da VCN para a sub-rede da camada de apresentação:

  Entrada com monitoramento de estado: Bloco CIDR de origem do VCN no TCP, porta de origem = todos, porta de destino = 14502–14510, 5150

• Para permitir o tráfego da camada do banco de dados para a camada intermediária:

  Saída com monitoramento de estado: Destino 0.0.0.0/0 no TCP, porta de origem = todos, porta de destino = todos