1. Saiba mais sobre a implantação do PeopleSoft no Oracle Cloud Infrastructure
  2. Saiba Mais Sobre a Implantação do PeopleSoft no Oracle Cloud Infrastructure

Saiba Mais Sobre a Implantação do PeopleSoft no Oracle Cloud Infrastructure

Se quiser provisionar aplicativos do OraclePeopleSoft no Oracle Cloud Infrastructure ou migrar ambientes do PeopleSoft de seu data center para o Oracle Cloud Infrastructure, você pode planejar uma topologia com vários hosts, segura e de alta disponibilidade.

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

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

Sub-redes Privadas ou Públicas

Você pode criar instâncias em uma sub-rede privada ou pública com base em se deseja permitir o acesso às instâncias da internet. As instâncias que você cria em uma sub-rede pública recebem um endereço IP público e você pode acessar essas instâncias na Internet. Não é possível designar um endereço IP público para instâncias criadas em uma sub-rede privada. Portanto, você não pode acessar essas instâncias na internet.

A imagem a seguir mostra uma VCN (rede virtual na nuvem) com sub-redes públicas e privadas. A VCN contém dois domínios de disponibilidade, e cada domínio de disponibilidade contém um subinet público e privado. Os servidores web são colocados na sub-rede pública nesta imagem, de modo que as instâncias do servidor web tenham um endereço IP público anexado a ele. Você pode acessar essas instâncias do Oracle Cloud na sub-rede pública da internet ativando a comunicação por meio do gateway de internet (IGW). Você terá de atualizar a tabela de rota para permitir que o tráfego seja feito no IGW. Para permitir o tráfego para os servidores Web pela internet, é necessário criar balanceadores de carga na sub-rede pública. Para acessar suas instâncias pela internet, você também precisa criar um host de bastão na sub-rede pública e acessar o host de bastecimento do IGW.

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


A descrição de public_private_subnets_jde.png é mostrada a seguir
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 em que não haja pontos finais internet-facing. Esse tipo de implantação é útil quando você deseja ter uma implantação híbrida na nuvem como uma extensão em seus data centers existentes.

Nesta implantação, todas as instâncias, inclusive servidores de aplicativos e de 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 na internet. Para acessar seus servidores de aplicativos do seu ambiente on-premises 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 de bastante nesta configuração e acesse todos os servidores na sub-rede privada a partir do host de bastecimento.

Cenário 2: Implantar Instâncias nas Sub-redes Públicas e Privadas

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 pontos finais de acesso de internet e não padrão.

Nesta configuração, algumas instâncias do aplicativo são colocadas em uma sub-rede pública e outras são colocadas em uma sub-rede privada. Por exemplo, você pode ter instâncias de aplicativos que servem a usuários internos e a outro conjunto de instâncias de aplicativos que servem a usuários externos. Neste cenário, coloque as instâncias do aplicativo que servem 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 do aplicativo voltadas para a Internet, em vez de colocar os servidores de aplicativos que atendem ao tráfego externo em uma sub-rede pública. Se você colocar o host de bastão em uma sub-rede pública, então o host de bastão 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 de bastecimento.

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

A Oracle recomenda esta implantação para demonstrações rápidas ou para implantações em nível de produção sem pontos finais internos. Esta implantação é adequada somente se você não tiver seu próprio data center, ou não puder acessar instâncias em VPN, e quiser acessar a infraestrutura na internet.

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

Cada instância na sub-rede pública tem um endereço IP público anexado a ela. Embora as instâncias com endereços IP públicos possam ser acessadas na 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 de bastion nesta configuração. Neste cenário, você não abriria portas de administração para a internet pública, mas, em vez disso, abre as portas de administração somente para o host de bastão e as listas de segurança de configuração e regras de segurança para garantir que a instância possa ser acessada somente pelo host de bastecimento.

Antiafinidade

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 com 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 modo que elas não estejam no mesmo hardware físico dentro de um único domínio de disponibilidade. Portanto, uma falha de hardware ou a manutenção de hardware do Oracle Compute que afete um domínio de falha não afeta as instâncias de outros domínios de falha. Usando domínios de falha, você pode proteger suas instâncias contra falhas inesperadas de hardware e paralisações planejadas.

Para obter alta disponibilidade de bancos de dados, você pode criar sistemas de banco de dados 2-node Oracle Real Application Clusters (Oracle RAC). Os dois nós do Oracle RAC são sempre criados em domínios de falha separados por default. 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 com o host físico subjacente e o topo das falhas de switch de rack.

Arquitetura

Saiba mais sobre os principais conceitos que podem ser usados para planejar estas opções de implantação para o PeopleSoft :

  • Arquitetura para implantar o PeopleSoft em um domínio de disponibilidade única, garantindo alta disponibilidade. Use esta arquitetura quando quiser garantir que sua aplicação esteja disponível mesmo quando uma instância da aplicação estiver desativada. As outras instâncias da aplicação disponíveis no domínio de disponibilidade continuam a processar as solicitações.

  • Arquitetura para implantar o PeopleSoft em vários domínios de disponibilidade ao garantir alta disponibilidade. Use esta arquitetura quando quiser garantir que sua aplicação esteja disponível mesmo quando um domínio de disponibilidade ficar inativo. Você ainda pode acessar as instâncias do aplicativo em outro domínio de disponibilidade.

  • Arquitetura para implantar o PeopleSoft , assegurando alta disponibilidade e recuperação de desastres. Use esta arquitetura quando quiser configurar um local de recuperação de desastres para o aplicativo em uma região diferente.

A arquitetura é válida para implantações do PeopleSoft feitas manualmente ou usando ferramentas de automação do PeopleSoft no Oracle Cloud Infrastructure.

Todos os diagramas de arquitetura são recomendados com a consideração de que você não deseja acessar seu banco de dados e os hosts de aplicativos na internet.

Arquitetura para Implantar o PeopleSoft em um Domínio de Disponibilidade Única

Esta arquitetura mostra a implantação de uma aplicação PeopleSoft em um único domínio de disponibilidade, garantindo alta disponibilidade.

A arquitetura consiste em uma VCN com o bastion, o balanceador de carga, a aplicação e os hosts de banco de dados colocados em sub-redes separadas da VCN em um único domínio de disponibilidade. O host de bastecimento é implantado em uma sub-rede pública e todas as outras instâncias são implantadas em sub-redes privadas. Você pode colocar as diferentes 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 na porta 22 por meio do host bastion ou do DRG se tiver configurado um túnel IPSec VPN entre seu data center e o Oracle Cloud Infrastructure DRG.

Nesta arquitetura, instâncias redundantes são implantadas na camada do aplicativo e da do banco de dados para garantir alta disponibilidade no domínio de disponibilidade. Isso garante que a aplicação esteja disponível mesmo quando uma instância da aplicação fica inativa. As outras instâncias da aplicação disponíveis no domínio de disponibilidade continuam a processar as solicitações. Todas as instâncias do aplicativo no domínio de disponibilidade estão ativas. As instâncias do balanceador de carga recebem solicitações e as envia para os servidores de aplicativos. Essa alta disponibilidade de um aplicativo em um domínio de disponibilidade pode ser realizada colocando instâncias do aplicativo em domínios de falha separados. Os domínios de falha permitem que você distribua suas instâncias de modo que elas não estejam no mesmo hardware físico dentro de um único domínio de disponibilidade. Como resultado, uma falha de hardware ou manutenção de hardware que afeta um domínio de falha não afeta As instâncias de outros domínios de falha.

As instâncias na sub-rede privada requerem conexão de saída com a Internet para fazer download de patches e também para aplicar atualizações do sistema operacional e da aplicação. 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 de aplicativos no Oracle Cloud Infrastructure Object Storage . Os bancos de dados e as instâncias da aplicação em sub-redes privadas podem ser submetidos a backup no 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 percorrer a 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 exige 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 de TDE (Transparent Data Encryption). O serviço de backup automático do banco de dados usa a estratégia de backup incremental semanal para fazer backup de bancos de dados com uma política de retenção do 30-day. 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ê o recurso para executar backups de volume automaticamente com base em uma programação e mantê-los com base na política de backup selecionada. Isso permite que você siga seus requisitos regulatórios e de conformidade de dados. Há três políticas de backup predefinidas: Bronze, Silver e Ouro. Cada política de backup tem uma frequência de backup e um período de retenção predefinidos.


A descrição de peoplesoft_single_availability_domain_ha_topology.png é mostrada a seguir
Descrição da ilustração peoplesoft_single_availability_domain_ha_topology.png
Esta arquitetura é dividida nestas camadas:

  • Host de bash: O host de bastion é um componente opcional que você pode usar como um servidor de salto para acessar as instâncias na sub-rede privada.

  • Camada do Balanceador de Carga: esta camada contém as instâncias do Oracle Cloud Infrastructure Load Balancing que carregam o tráfego nos servidores Web PeopleSoft. O balanceador de carga recebe solicitações de usuários e encaminha essas solicitações para a camada do aplicativo.

  • Camada de aplicativos: essa camada contém instâncias redundantes dos servidores de aplicativos PeopleSoft , dos servidores PeopleSoft Web, dos servidores ElasticSearch e do PeopleSoft Process Scheduler para oferecer alta disponibilidade. Configure instâncias redundantes de todos os servidores na camada da aplicação para garantir que você possa continuar acessando a aplicação mesmo que uma instância fique inativa.

  • Cliente PeopleTools: use o cliente PeopleTools para executar atividades de administração, como desenvolvimento, migração e atualização.

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

Arquitetura para Implantar o PeopleSoft em Vários Domínios de Disponibilidade

Esta arquitetura mostra a implantação dos servidores de aplicativos PeopleSoft em vários domínios de disponibilidade. Mostra uma VCN com o bastante, balanceador de carga, aplicação e hosts de banco de dados colocados em sub-redes separadas entre dois domínios de disponibilidade.

No diagrama de arquitetura, o host de bastecimento é 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 na porta 22 por meio do host bastion ou do DRG se tiver configurado um túnel IPSec VPN entre seu data center e o Oracle Cloud Infrastructure DRG. Todas as instâncias estão ativas nos dois domínios de disponibilidade. Os únicos componentes passivos na arquitetura são os hosts do banco de dados no Domínio de Disponibilidade 2.

Os hosts de bastecimento no Domínio de Disponibilidade 1 e no Domínio de Disponibilidade 2 estão ativos e podem atender solicitações SSH a instâncias em ambos os domínios de disponibilidade em todos os momentos. O DNS local ou serviço DNS externo recebe a solicitação de aplicativo PeopleSoft . Essas solicitações são a carga com revezamento balanceada para um dos balanceadores de carga no Domínio de Disponibilidade 1 ou 2. O balanceador de carga encaminhará então a solicitação para um dos servidores web PeopleSoft subjacentes no Domínio de Disponibilidade 1 ou 2. O servidor Web PeopleSoft roteia a solicitação a um dos servidores de aplicativos PeopleSoft e, finalmente, o servidor de aplicativos encaminha as solicitações para as instâncias de banco de dados ativas no Domínio de Disponibilidade 1 para processamento.

Se o Domínio de Disponibilidade 1 não estiver disponível, você deverá remover manualmente a entrada do balanceador de carga do Domínio de Disponibilidade 1 do serviço de DNS e fazer switchover do banco de dados para as instâncias do banco de dados no Domínio de Disponibilidade 2. As solicitações recebidas do serviço DNS agora são roteadas para o balanceador de carga no Domínio de Disponibilidade 2 e, em seguida, finalmente, para o banco de dados no Domínio de Disponibilidade 2 para processamento.


A descrição de peoplesoft_multiple_availability_domain_ha_topology.png é mostrada a seguir
Descrição da ilustração peoplesoft_multiple_availability_domain_ha_topology.png

  • Host de bash: Um host de persistência é um componente opcional que você pode provisionar em cada domínio de disponibilidade para atuar como um host de salto para acessar as instâncias da aplicação e do banco de dados. Os hosts bash no Domínio de Disponibilidade 1 e no Domínio de Disponibilidade 2 estão no estado ativo.

  • Instâncias do balanceador de carga: as instâncias do Oracle Cloud Infrastructure Load Balancing distribuem o tráfego entre os servidores de aplicações nos dois domínios de disponibilidade. As instâncias do balanceador de carga no Domínio de Disponibilidade 1 e 2 estão ativas. As solicitações recebidas no URL do PeopleSoft são balanceadas com revezamento em um balanceador de carga no Domínio de Disponibilidade 1 ou 2 por um serviço DNS externo ou local.

  • Camada de aplicativos: o Domínio de Disponibilidade 1 e o Domínio de Disponibilidade 2 contêm instâncias redundantes do servidor de aplicativos PeopleSoft , o servidor Web PeopleSoft , os servidores do ElasticSearch e o PeopleSoft Process Scheduler. Todas as instâncias na camada da aplicação nos dois domínios de disponibilidade estão no estado ativo.

  • Cliente PeopleTools: use o cliente PeopleTools para executar atividades de administração, como desenvolvimento, migração e atualização.

  • Camada do banco de dados: configure instâncias do banco de dados altamente disponíveis nos dois domínios de disponibilidade. O Domínio de Disponibilidade 1 hospeda as instâncias do banco de dados principal. O Domínio de Disponibilidade 2 hospeda as instâncias do banco de dados stand-by. Em cada domínio de disponibilidade, pelo menos duas instâncias do banco de dados são configuradas para garantir alta disponibilidade. Se uma instância do banco de dados não estiver disponível no Domínio de Disponibilidade 1, a segunda instância do banco de dados no Domínio de Disponibilidade 1 continuará processando as solicitações.

    Use o Oracle Active Data Guard no modo síncrono para replicar o banco de dados entre os domínios de disponibilidade em uma região.

Arquitetura para Implantação do PeopleSoft em Várias Regiões

Esta arquitetura mostra a implantação dos servidores de aplicativos PeopleSoft em várias regiões, garantindo alta disponibilidade e recuperação de desastres. Mostra uma VCN com bastante, balanceador de carga, aplicativo e instâncias de banco de dados colocados em sub-redes separadas entre duas regiões. Para garantir que você possa acessar as instâncias da aplicação PeopleSoft , mesmo quando todos os domínios de disponibilidade de uma região ficarem desativados, implante o PeopleSoft em várias regiões.

O diagrama de arquitetura mostra duas regiões. Na Região 1, o PeopleSoft é implantado em vários domínios de disponibilidade para garantir a alta disponibilidade entre os domínios de disponibilidade dentro de uma região. Região 2 é a região de recuperação de desastres. Todas as instâncias estão ativas nos dois domínios de disponibilidade na Região 1. Os componentes passivos na arquitetura são os hosts do banco de dados no Domínio de Disponibilidade 2 e todas as instâncias na Região 2. A Oracle recomenda que o número de instâncias que você implanta para cada camada no domínio de disponibilidade na Região 2 seja o mesmo que o número de instâncias implantadas em um domínio de disponibilidade na Região 1. Isso garante que as instâncias do aplicativo podem levar o carregamento inteiro depois que a recuperação de desastre for chamada.

Também é possível ter essa arquitetura implantada em apenas um domínio de disponibilidade na região 1 e um domínio de disponibilidade na região 2 para recuperação de desastre. No entanto, esta arquitetura não fornece tolerância a falhas para o domínio de disponibilidade na região 1. Se o único domínio de disponibilidade onde o aplicativo foi implantado não estiver disponível, você precisará chamar a recuperação de desastres para fazer failover do seu aplicativo para a região 2.

Na Região 1, os hosts de bastecimento no Domínio de Disponibilidade 1 e no Domínio de Disponibilidade 2 estão ativos e podem servir solicitações SSH para instâncias em ambos os domínios de disponibilidade em todos os momentos. O DNS local ou serviço DNS externo recebe a solicitação de aplicativo PeopleSoft . Essas solicitações são a carga com revezamento balanceada para um dos balanceadores de carga no Domínio de Disponibilidade 1 ou 2. O balanceador de carga encaminhará então a solicitação para um dos servidores web PeopleSoft subjacentes no Domínio de Disponibilidade 1 ou 2. O servidor Web PeopleSoft roteia a solicitação a um dos servidores de aplicativos PeopleSoft e, finalmente, o servidor de aplicativos encaminha as solicitações para as instâncias de banco de dados ativas no Domínio de Disponibilidade 1 para processamento.

Se as instâncias na Região 1 não estiverem disponíveis, alterne manualmente para as instâncias na Região 2. Nesse cenário, o balanceador de carga e as instâncias do banco de dados na Região 2 agem como o balanceador de carga principal e as instâncias do banco de dados. As solicitações recebidas no URL do PeopleSoft são roteadas para o balanceador de carga na Região 2, que depois roteiam o tráfego para o servidor Web do PeopleSoft subjacente na Região 2. Os servidores Web do PeopleSoft roteiam a solicitação para as instâncias do aplicativo PeopleSoft e, em seguida, os servidores de aplicativos do PeopleSoft encaminham as solicitações para as instâncias do banco de dados na Região 2 para processamento.

No diagrama de arquitetura, o host de bastion e o balanceador de carga são implantados em sub-redes públicas 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 na porta 22 por meio do host bastion ou do DRG se tiver configurado um túnel IPSec VPN entre seu data center e o Oracle Cloud Infrastructure DRG.


A seguir, descrição de peoplesoft_multiple_regions_ha_topology.png
Descrição da ilustração peoplesoft_multiple_regions_ha_topology.png

Esta arquitetura suporta estes componentes:

  • Host de bash: Um host de persistência é um componente opcional que você pode provisionar em cada domínio de disponibilidade para atuar como um host de salto para acessar as instâncias da aplicação e do banco de dados. Os hosts bash no Domínio de Disponibilidade 1 e no Domínio de Disponibilidade 2 estão no estado ativo.

  • Instâncias do balanceador de carga: as instâncias do Oracle Cloud Infrastructure Load Balancing distribuem o tráfego entre os servidores de aplicações nos domínios de disponibilidade. O Domínio de Disponibilidade 1 e 2 na Região 1 hospeda as instâncias do balanceador de carga principal.

  • Camada da aplicação: o Domínio de Disponibilidade 1 e o Domínio de Disponibilidade 2 na Região 1 contêm pelo menos uma instância do servidor de aplicativos do PeopleSoft , o servidor Web do PeopleSoft, os servidores do ElasticSearch e o PeopleSoft Process Scheduler. Todas as instâncias nos dois domínios de disponibilidade da Região 1 estão no estado ativo. As instâncias da camada do aplicativo na Região 2 estão no estado passivo. Para sincronizar servidores de aplicativos entre domínios de disponibilidade e entre as regiões, use rsync.

  • Cliente PeopleTools: use o cliente PeopleTools para executar atividades de administração, como desenvolvimento, migração e atualização.

  • Camada do banco de dados: O Domínio de Disponibilidade 1 na Região 1 hospeda as instâncias do banco de dados principal. O Domínio de Disponibilidade 2 na Região 1 e Região 2 são instâncias do banco de dados stand-by. Em cada domínio de disponibilidade, pelo menos duas instâncias do banco de dados são configuradas para garantir alta disponibilidade. Se uma instância do banco de dados ficar inativa no Domínio de Disponibilidade 1, a segunda instância do banco de dados no Domínio de Disponibilidade 1 continuará processando as solicitações. Se Região 1 não estiver disponível, as instâncias do banco de dados na Região 2 processarão as solicitações.

    A Oracle recomenda usar o Oracle Active Data Guard no modo síncrono para replicar o banco de dados entre os domínios de disponibilidade em uma região. Para replicar o banco de dados entre regiões, use o Oracle Active Data Guard no modo assíncrono.