Prepare a camada Web no OCI

Provisione e configure seu site secundário no Oracle Cloud Infrastructure (OCI) para ser consistente com seu site principal local.

Observação:

Você pode encontrar o código do Terraform para criar os recursos descritos nesta seção (o Balanceador de Carga do OCI, o certificado SSL, os conjuntos de backend e backends, as políticas de roteamento, os listeners e os conjuntos de regras) em Fazer Download do Código.

(Opcional) Preparar os Hosts do Oracle HTTP Server

Crie e configure as instâncias de computação do Oracle HTTP Server no Oracle Cloud Infrastructure.

Observação:

A criação e a configuração do Oracle HTTP Server são opcionais. Você pode configurar a camada web no OCI usando apenas o Balanceador de Carga do OCI (sem usar o Oracle HTTP Server).

Provisionar os Hosts do Oracle HTTP Server

Crie uma instância de computação na sub-rede da camada Web do Oracle Cloud Infrastructure (OCI) para cada host principal do Oracle HTTP Server local. As instâncias de computação devem usar a imagem do sistema operacional e a forma de computação mais semelhantes à imagem e à forma usadas pelos hosts locais do Oracle HTTP Server.

Cada Oracle HTTP Server em execução no OCI deve ter um contrato de Licença e suporte válido, além do contrato de Licença e suporte usado para cobrir o Oracle HTTP Server em execução no local. Você pode usar imagens do Oracle WebLogic Server for OCI para criar instâncias de computação para o Oracle HTTP Server na Oracle Cloud. As instâncias de computação criadas com essas imagens incluem o direito de executar o Oracle HTTP Server e são cobradas por OCPU/Hora pelo direito de executar o software WebLogic quando estão no estado de execução. Ao criar as instâncias de computação com o Oracle WebLogic Server for OCI, você pode usar a Console da Instância do Serviço Compute ou o Marketplace. Essas imagens estão disponíveis para os sistemas operacionais Oracle Linux 7.9 e Oracle Linux 8.5.

Este exemplo usa duas instâncias de computação em um único domínio de disponibilidade dentro do compartimento, conforme mostrado na tabela.

Nome	Compartimento	Domínio de Disponibilidade	Imagem	Forma	VCN	Sub-rede
hydrohs1	HyDRCompmt	AD1	Imagem do UCM do Oracle WebLogic Enterprise Edition (Oracle Linux 7.9)	VM.Standard2.2	hidrvcn	webTierSubnet
hydrohs2	HyDRCompmt	AD1	Imagem do UCM do Oracle WebLogic Enterprise Edition (Oracle Linux 7.9)	VM.Standard2.2	hidrvcn	webTierSubnet

Execute o seguinte para provisionar instâncias de computação usando a Console da Instância do Compute:

1. Acesse a Console do OCI para sua tenancy.
2. Selecione a região apropriada.
3. Clique no menu de navegação, selecione Compute. Clique em Instâncias e, em seguida, clique em Criar Instância.
4. Informe nomes para a instância de computação e o compartimento.
5. Em Colocação, selecione o Domínio de Disponibilidade no qual a instância será criada. Se a Região do OCI tiver mais de um Domínio de Disponibilidade, você poderá colocar as instâncias de computação WebLogic em diferentes Domínios de Disponibilidade.
6. Em Imagem e Forma, clique em Alterar Imagem e execute o seguinte:
   1. Na lista drop-down Origem da imagem, selecione Imagens da Oracle e, em seguida, selecione Imagem do UCM do Oracle WebLogic Server Enterprise Edition na lista de imagens do Oracle WebLogic Server for OCI.
   2. Para a imagem selecionada, clique na seta à direita e selecione a versão de build da imagem para as imagens pagas.
      • Oracle Linux 7.9 (denominado release-ol7.9-build-timestamp)
      • Oracle Linux 8.5 (identificado como release-ol8.5-build-timestamp)
   3. Verifique os termos e as condições. Marque a caixa de seleção Termos de Uso da Oracle e clique em Selecionar Imagem.
7. Em Imagem e Forma, clique em Alterar Forma. Selecione o Tipo de Instância e selecione a forma mais semelhante aos hosts principais.
   Consulte Imagens do Oracle WebLogic Server para OCI para obter uma lista de formas suportadas.
8. Selecione a VCN, a sub-rede (sub-rede da camada web) e o Domínio de Disponibilidade do seu ambiente.
   Para especificar o tipo de capacidade e o domínio de falha, clique em Mostrar opções avançadas.
9. Configure a rede da instância. Para especificar configurações de rede avançadas, clique em Mostrar opções avançadas.
10. Em Adicionar chaves SSH, crie uma chave, faça upload de sua chave pública ou cole as chaves.
11. Em Volume de Inicialização, especifique as opções de tamanho e criptografia para o volume de inicialização da instância.
12. Clique em Mostrar opções avançadas para configurar definições avançadas.
13. Clique em Criar.
14. Repita as etapas para criar outra instância de computação.

Preparar os Grupos e Usuários do Sistema Operacional

O mesmo usuário e grupo usados pelo software Oracle local principal são necessários nas instâncias de computação secundárias.

As imagens do Oracle WebLogic Server for Oracle Cloud Infrastructure já têm um usuário e um grupo da oracle. No entanto, esses valores (nome do usuário, nome do grupo, uid e gid) podem não corresponder aos valores que você tem na sua instância principal e você precisará configurar os hosts secundários para corresponder aos valores do usuário e do grupo oracle principal. Os exemplos a seguir mostram como configurar os hosts secundários nesta camada para corresponder aos valores do usuário e do grupo oracle principais.

Cada grupo e usuário nas instâncias de computação do OCI devem ter o mesmo ID em cada nó e o mesmo que no principal.

1. Identifique o usuário, o grupo e os IDs do usuário oracle nos hosts principais fazendo log-in em um host local com o usuário oracle e, em seguida, use o comando id.

   [[e-mail] ~]$ id
   uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)
   
   [[e-mail] ~]$ more /etc/passwd | grep oracle
   oracle:x:1001:1002::/home/oracle:/bin/bash

   A tabela a seguir mostra um exemplo de usuário e grupos para um ambiente local típico.

   Usuário ou Grupo	Nome	ID	Descrição
   Usuário	oracle	1001	O proprietário do software Oracle
   Grupos	oinstall	1002	Grupo principal do usuário oracle
   	dba	1001	Grupo secundário do usuário oracle

2. Identifique os usuários, os grupos e os IDs que existem nos hosts secundários usando SSH para acessar sua instância recém-criada como o usuário opc. Faça log-in em hosts secundários com o usuário opc, depois de sudo para o usuário oracle e execute o comando id.

   [opc@hydrsoa1 ~]$ sudo su - oracle
   [oracle@hydrsoa1 ~]$ id
   uid=1001(oracle) gid=1001(oracle) groups=1001(oracle),1002(docker) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

   A tabela a seguir mostra o usuário oracle e o grupo que já existem nas instâncias de computação secundárias.

   Usuário ou Grupo	Nome	ID	Descrição
   Usuário	oracle	1001	O proprietário do software Oracle
   Grupos	oracle	1001	Grupo principal do usuário oracle
   	docker	1002	Grupo secundário do usuário oracle

3. Estes são os cenários e soluções possíveis:
   • Os usuários e grupos no secundário são nomes e IDs diferentes dos principais.

     Solução: Crie os usuários e grupos na instância secundária à medida que eles existirem na instância principal.

   • Os usuários e grupos em secundário são os mesmos nomes, mas IDs diferentes do principal.

     Solução: altere os IDs no secundário para corresponder aos IDs do principal.

   • Os usuários e grupos do secundário são nomes diferentes dos nomes do principal, mas os mesmos IDs.

     Solução: Altere os nomes do usuário e do grupo no secundário.

   • Há conflitos: alguns IDs do usuário ou grupos principais são usados por outros usuários ou grupos no secundário.

     Solução: Corrija o conflito alterando o ID do usuário ou grupo conflitante no secundário e, em seguida, crie o usuário ou os grupos no secundário para corresponder aos que estão no principal.

   A tabela a seguir é um resumo dos comandos que podem ser usados para resolver conflitos:

   Ação	Comando (executar como raiz)
   Para criar um novo grupo	groupadd group_name -g group_id Por exemplo: groupadd oinstall -g 1002 groupadd dba -g 1001
   Para criar um novo usuário	useradd -u user_id user_name -g principal_group -G other groups Por exemplo: useradd -u 1001 oracleuser -g oinstall -G dba
   Para alterar o grupo principal do usuário	usermod -g new_primary_groupname user_name
   Para adicionar um usuário a um grupo	usermod -a -G secondary_groupname user_name
   Para alterar o ID de um usuário	usermod -u new_id user_name find / -user old_uid -exec chown -h user_name {} \; Por exemplo, o seguinte altera o ID do usuário oracle de 1001 para 501: usermod -u 501 oracle find / -user 1001 -exec chown -h oracle {} \;
   Para alterar o ID de um grupo	groupmod -g new_id group_name find / -group old_id -exec chgrp -h group_name {} \; Por exemplo, o seguinte altera o ID do grupo oracle de 1001 para 501: groupmod -g 501 oracle find / -user 1001 -exec chgrp -h oracle {} \;

   Observação:

   A Oracle recomenda a execução das alterações nas instâncias de computação secundárias do OCI. Não modifique os valores de ID no principal.

   Veja a seguir um exemplo em que os IDs dos grupos usados nos hosts principais já são usados por outros grupos nos hosts secundários. Para resolver esse conflito, são necessárias as seguintes ações:

   1. O grupo docker no secundário está usando o ID 1002, que está em conflito com o ID do grupo principal oinstall.
      Para resolver o conflito, altere o ID do grupo docker nos hosts secundários para um ID diferente e não conflitante. Por exemplo, selecione 1005 como o novo ID e verifique se ele não é usado confirmando que ele não aparece no arquivo /etc/group.

      [opc@hydrsoa1 ~]$ sudo -s  
      [root@hydrsoa1 ~]$ more /etc/group | grep 1005

      Quando você confirmar que o ID não é utilizado, altere o ID do grupo para o novo ID.

      [opc@hydrsoa1 ~]$ sudo -s 
      [root@hydrsoa1 ~]$ groupmod -g 1005 docker
      [root@hydrsoa1 ~]$ find / -group 1002 -exec chgrp -h docker {} \;

   2. O grupo oracle no secundário usa o ID 1001, que está em conflito com o id do grupo principal dba.
      Para resolver o conflito, altere o ID do grupo oracle nos hosts secundários para um ID diferente e não conflitante. Por exemplo, selecione 1006 como o novo ID e verifique se ele não é usado confirmando que não aparece no arquivo /etc/group.

      [opc@hydrsoa1 ~]$ sudo -s 
      [root@hydrsoa1 ~]$ more /etc/group | grep 1006

      Quando você confirmar que o ID não é utilizado, altere o ID do grupo para o novo ID.

      [opc@hydrsoa1 ~]$ sudo -s 
      [root@hydrsoa1 ~]$ groupmod -g 1006 oracle
      [root@hydrsoa1 ~]$ find / -group 1001 -exec chgrp -h oracle {} \;

   3. Crie grupos de usuários oracle oinstall e dba nos hosts secundários com os mesmos IDs dos IDs principais.

      [opc@hydrsoa1 ~]$ sudo -s
      [root@hydrsoa1 ~]$ groupadd oinstall -g 1002
      [root@hydrsoa1 ~]$ groupadd dba -g 1001

   4. O usuário oracle tem o mesmo nome e ID no principal e no stand-by; portanto, não são necessárias alterações.
      No entanto, você precisa alterar o grupo principal do usuário para oinstall nos hosts secundários.

      [root@hydrsoa1 ~]$ usermod -g oinstall oracle

      Em seguida, adicione o usuário ao grupo dba.

      [root@hydrsoa1 ~]$ usermod -a -G dba oracle

   5. Confirme se a saída do comando id para o usuário oracle nos hosts secundários corresponde à principal para os grupos principal e secundário.
      Saída na instância principal:

      [[e-mail] ~]$ id
      uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)

      Saída no secundário (o secundário pode ter grupos adicionais):

      oracle@hydrsoa1 ~]$ id
      uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba),1005(docker)
              …

   6. (Recomendado) Execute uma reinicialização do host após essas alterações.
4. (Opcional, mas recomendado) Ative o acesso SSH ao usuário oracle.
   Ela é útil nesta topologia de DR porque permite ao usuário oracle uma conexão direta para executar os comandos usados para copiar o conteúdo do sistema de arquivos da principal para a secundária.
   1. Copie a chave pública que você usa para estabelecer conexão com as instâncias de computação para um arquivo de texto. Você o usará mais adiante neste procedimento.
   2. Faça log-in na instância e sudo no usuário raiz.
   3. Crie um diretório .ssh no diretório home do novo usuário.

      mkdir -p /home/oracle/.ssh

   4. Copie a chave pública SSH usada para estabelecer conexão com a computação no arquivo.

      /home/oracle/.ssh/authorized_keys

   5. Altere o proprietário e o grupo do diretório /home/oracle/.ssh para o usuário oracle.

      chown -R oracle:oinstall /home/oracle/.ssh

   6. Verifique a conexão conectando-se ao SSH usando o usuário oracle e sua chave privada.
   7. Faça com que as permissões do arquivo authorized_keys sejam 600.

      chmod 600 /home/oracle/.ssh/authorized_keys

Preparar os Requisitos do Sistema Operacional

Os binários do Oracle HTTP Server serão copiados dos hosts principais do Oracle HTTP Server para os hosts secundários do Oracle HTTP Server. Portanto, não é necessário executar o runinstaller nos hosts secundários. Como as imagens do Oracle WebLogic Server for Oracle Cloud Infrastructure estão preparadas para o software WebLogic, você não precisa adicionar pacotes manualmente para WebLogic. No entanto, esses hosts do Oracle HTTP Server executarão o produto Oracle HTTP Server. Verifique se os hosts secundários atendem aos requisitos do Oracle HTTP Server.

1. Certifique-se de que seu ambiente atenda aos requisitos mínimos de instalação para os produtos instalados nos hosts principais. Verifique o documento correspondente no Oracle Fusion Middleware System Requirements and Specifications.
2. Verifique OS pacotes de sistema necessários para a versão e o SO.
3. Instale os pacotes de sistema ausentes com o yum.

   Este exemplo usa o Oracle HTTP Server 12.2.1.4 e o Oracle Linux 7. Alguns dos pacotes necessários já estão instalados nas instâncias de computação da camada intermediária do Oracle Cloud Infrastructure (OCI). Neste exemplo, os itens a seguir estavam ausentes e precisavam ser instalados usando o yum:

   yum install compat-libcap1.x86_64
   yum install compat-libstdc++-33.x86_64
   yum install compat-libstdc++-33.i686 
   yum install gcc-c++.x86_64
   yum install libaio-devel.x86_64
   yum install libstdc++.i686    
   yum install libstdc++-devel.x86_64
   yum install dejavu-serif-fonts
   yum install numactl.x86_64
   yum install numactl-devel.x86_64
   yum install motif.x86_64
   yum install motif-devel.x86_64
   yum install redhat-lsb.x86_64
   yum install xorg-x11-utils.x86_64
   

4. Configure limites de arquivo e proc no arquivo /etc/security/limits.conf. Verifique os limites em seus hosts locais do Oracle HTTP Server e defina os valores nas instâncias de computação do Oracle HTTP Server do OCI de acordo.

Preparar os Aliases de Nome de Host para o Oracle HTTP Server

Configure os mesmos nomes de host virtual usados pelos hosts do Oracle HTTP Server no ambiente principal como aliases nas instâncias de computação secundárias do Oracle Cloud Infrastructure (OCI) Oracle HTTP Server, mas aponte para os endereços IP dos hosts secundários.

Isso pode ser implementado de 2 formas:

• Adicione os nomes de host como aliases aos arquivos /etc/hosts das instâncias de computação do Oracle WebLogic Server for OCI.
• Use uma view de DNS privado na VCN do OCI secundária.

Usar Arquivos /etc/hosts

Os nomes de host virtual usados como aliases nos servidores principais são adicionados aos arquivos /etc/hosts dos hosts secundários, apontando para os endereços IP dos hosts secundários. Esse modo é válido em todos os cenários quando o servidor DNS é o mesmo no local principal e nos sites secundários do Oracle Cloud Infrastructure (OCI) e também quando servidores DNS separados são usados nos sites principal e secundário. As entradas no arquivo /etc/hosts têm precedência sobre a resolução de DNS, porque essa é a precedência definida pronta para uso na diretiva "hosts" do arquivo /etc/nsswitch.conf.

No entanto, esse método requer que você adicione manualmente as entradas a todos os hosts do Oracle HTTP Server:

1. Edite o arquivo /etc/oci-hostname.conf de cada instância de computação do Oracle HTTP Server e defina a propriedade PRESERVE_HOSTINFO=3 para preservar as entradas /etc/hosts nas reinicializações da instância.
2. Use o comando hostname --fqdn para identificar os nomes de host completos das instâncias de computação do OCI.
3. Adicione as seguintes entradas ao arquivo /etc/hosts das instâncias de computação do Oracle HTTP Server do OCI:

   #################################
   # ALIASES for SOA DR
   #################################
   # Aliases of the Oracle HTTP Server hosts
   ohshost1_compute_instance_IP  ohshost1_fqdn  ohshost1_hostname    ALIASES_OF_WEBHOST1
   ohshost2_compute_instance_IP  ohshost2_fqdn  ohshost2_hostname    ALIASES_OF_WEBHOST2
   # The aliases for SOA are added too
   virtual_IP_for_admin          virtualIP_fqdn  virtualIP_hostname    ALIASES_OF_ADMINVHN
   soahost1_compute_instance_IP  soahost1_fqdn   soahost1_hostname     ALIASES_OF_SOAHOST1
   soahost2_compute_instance_IP  soahost2_fqdn   soahost2_hostname     ALIASES_OF_SOAHOST2

   Observação:

   Além de adicionar os nomes virtuais dos hosts do Oracle HTTP Server como aliases, os nomes virtuais dos hosts do Oracle WebLogic Server são adicionados, apontando para os IPs do host secundário do WebLogic Server. Como o Oracle HTTP Server se comunicará com os hosts do WebLogic Server usando seus nomes de hosts virtuais.
   Veja a seguir um exemplo do arquivo /etc/hosts na instância de computação secundária do Oracle HTTP Server:

   #################################
   # ALIASES for SOA DR - SECONDARY
   #################################
   # The aliases of the Oracle HTTP Server hosts
   100.60.10.11 hydrohs1.webTiersubnet.hydrvcn.oraclevcn.com    hydrohs1    WEBHOST1.example.com WEBHOST1
   100.60.10.12 hydrohs2.webTiersubnet.hydrvcn.oraclevcn.com    hydrohs2    WEBHOST2.example.com WEBHOST2
   # The aliases of the SOA hosts
   100.70.10.20 hydrsoa-vip.midTiersubnet.hydrvcn.oraclevcn.com hydrsoa-vip ADMINVHN.example.com ADMINVHN
   100.70.10.13 hydrsoa1.midTiersubnet.hydrvcn.oraclevcn.com    hydrsoa1    SOAHOST1.example.com SOAHOST1
   100.70.10.14 hydrsoa2.midTiersubnet.hydrvcn.oraclevcn.com    hydrsoa2    SOAHOST2.example.com SOAHOST2

   Veja a seguir um exemplo do arquivo /etc/hosts existente dos hosts principais do Oracle HTTP Server:

   #################################
   # ALIASES for SOA DR - PRIMARY
   #################################
   # The aliases of the Oracle HTTP Server hosts
   100.10.10.11 host1.myopnetwork.com    host1    WEBHOST1.example.com WEBHOST1
   100.10.10.12 host2.myopnetwork.com    host2    WEBHOST2.example.com WEBHOST2
   # The aliases of the SOA hosts
   10.10.10.20    host-vip1.myopnetwork.com         host-vip1       ADMINVHN.example.com   ADMINVHN
   10.10.10.13    host3.myopnetwork.com             host3           SOAHOST1.example.com   SOAHOST1
   10.10.10.14    host4.myopnetwork.com             host4           SOAHOST2.example.com   SOAHOST2

Usar o Sistema de Nomes de Domínio (DNS)

Os nomes de host virtual usados pelos hosts primários do Oracle HTTP Server são adicionados ao resolvedor de DNS usado pela VCN dos hosts secundários do Oracle HTTP Server, apontando para os endereços IP dos hosts secundários do Oracle HTTP Server. Esse modo é válido quando servidores DNS separados são usados no local principal e no secundário no Oracle Cloud Infrastructure (OCI). Caso contrário, poderá causar conflitos na resolução de nomes. O servidor de cada site deve resolver esses nomes com seus próprios IPs.

A vantagem desse método é que você pode adicionar todas as entradas a uma view de DNS privada, em vez de adicioná-las aos arquivos /etc/hosts de todos os hosts.

Adicione as entradas dos nomes de host virtual do Oracle HTTP Server à View Privada criada no OCI na etapa Preparar a Camada Intermediária no OCI:

1. Na Console do OCI, vá para a região secundária e localize a view privada:
   1. Clique em Rede, Gerenciamento de DNS, Views Privadas.
      Por exemplo, HYBRID_DR_VIRTUAL_HOSTNAMES
   2. Na view privada, clique no nome da zona que você criou para adicionar os hosts virtuais.
      Neste exemplo: example.com.
   3. Adicione os nomes de hosts virtuais do Oracle HTTP Server a essa zona, mas resolvidos com os IPs secundários dos hosts do Oracle HTTP Server.

      Você só precisa fornecer o nome não-fqdn no menu da Console do OCI para adicionar o registro. O domínio DNS da zona é adicionado automaticamente ao registro.

   4. Clique em Publicar alterações.
2. Valide os hosts SECONDARY de resolução fazendo ping e nslookup dos nomes de host virtual adicionados.
   Eles devem ser resolvidos com os IPs SECONDARY equivalentes.

Abra as Portas Necessárias nos Firewalls do Host do OCI

Cada instância de computação tem um serviço de firewall local. Por motivos de segurança, a configuração padrão é rejeitar as conexões de todas as portas, exceto o mínimo necessário (ssh, dhcp). Abra as portas usadas pelo Oracle HTTP Server.

1. Verifique o status e as regras do serviço de firewall:

   bash-4.2# firewall-cmd --state
   running
   bash-4.2# firewall-cmd --list-all
   public (active)
     target: default
     icmp-block-inversion: no
     interfaces: ens3
     sources:
     services: dhcpv6-client ssh
     ports:
     protocols:
     masquerade: no
     forward-ports:
     source-ports:
     icmp-blocks:
     rich rules:

   Essa saída significa que não há portas abertas diferentes de 22.
2. Como usuário raiz, use os comandos firewall-cmd para abrir as portas usadas como portas de listening pelo Oracle HTTP Server em cada instância de computação do Oracle HTTP Server.
   Por exemplo:

   firewall-cmd --permanent --add-port=7001/tcp 
   firewall-cmd --permanent --add-port=8890/tcp 
   service firewalld reload

3. Verifique o status e as regras do serviço de firewall:

   bash-4.2# firewall-cmd --list-all
   public (active)
     target: default
     icmp-block-inversion: no
     interfaces: ens3
     sources:
     services: dhcpv6-client ssh
     ports: 7001/tcp 8890/tcp 8888/tcp
     protocols:
     masquerade: no
     forward-ports:
     source-ports:
     icmp-blocks:
     rich rules:

Criar as Variáveis de Ambiente do Usuário oracle para o Oracle HTTP Server

É comum ter variáveis de ambiente relacionadas ao Oracle HTTP Server no perfil do usuário oracle nos hosts do Oracle HTTP Server. Por exemplo, ORACLE_HOME, JDK_HOME, PATH, WEB_DOMAIN_HOME e outros.

1. Revise os arquivos de perfil do usuário oracle nos hosts principais do Oracle HTTP Server.
2. Em secundário, adicione as mesmas variáveis de ambiente relacionadas ao Oracle HTTP Server aos arquivos de perfil do usuário oracle (.bashrc ou .bash_profile).

   Observe que o arquivo .bashrc do usuário oracle nos hosts do Oracle HTTP Server já pode conter variáveis definidas (MIDDLEWARE_HOME, WLS_HOME etc.), mas elas provavelmente serão para as pastas do seu ambiente e não serão válidas para você. Certifique-se de removê-los ou modificá-los de acordo com suas pastas de ambiente.

Replicar o Produto e a Configuração do Oracle HTTP Server do Principal

Como as instâncias de computação secundárias do Oracle HTTP Server do OCI são criadas como OS hosts principais do Oracle HTTP Server (o mesmo SO, IDs de usuário, aliases de nome de host etc.), você pode usar rsync para copiar OS binários e a configuração do Oracle HTTP Server dos nós principais do Oracle HTTP Server.

Como alternativa, você pode fazer download do software Oracle HTTP Server, instalá-lo e configurá-lo de zero nas instâncias de computação do Oracle HTTP Server do OCI. Esta abordagem está fora do escopo deste documento. No entanto, você deve usar essa abordagem quando as instâncias de computação do OCI do Oracle HTTP Server tiverem um sistema operacional diferente dos hosts principais do Oracle HTTP Server.

Os binários e os arquivos de configuração do Oracle HTTP Server normalmente residem no armazenamento privado. No OCI, você pode usar o volume em blocos que a instância de computação tem por padrão. Como alternativa, você pode criar um novo volume em blocos para cada computação do Oracle HTTP Server (conforme descrito em Preparar os Volumes em Blocos do OCI) e montar cada um nas instâncias de computação do Oracle HTTP Server (conforme descrito em Montar os Volumes em Blocos do OCI).

Este exemplo usa o volume em blocos padrão das instâncias de computação do Oracle HTTP Server sem criar volumes em blocos adicionais.

1. Identifique as pastas dos binários e da configuração do Oracle HTTP Server nos nós principais do Oracle HTTP Server.
   Por exemplo:

   ORACLE_HOME	/u02/oracle/products/ohs_12214
   WEB_DOMAIN_HOME	/u02/oracle/config/domains/ohsdomain_12214

2. Crie as mesmas pastas nas instâncias de computação do Oracle HTTP Server do OCI. É necessário usar o mesmo caminho que é usado na instância principal.
   1. SSH para as instâncias de computação do SO e sudo para o usuário root.
   2. Crie as pastas e torne oracle o proprietário.
      Por exemplo:

      bash-4.2# mkdir -p /u02/oracle/products/ohs_12214
      bash-4.2# mkdir -p /u02/oracle/config/ohsdomain_12214
      bash-4.2# chown -R oracle:oinstall /u02

   3. Repita para cada instância de computação do OCI do Oracle HTTP Server.
3. Use rsync para copiar a pasta produtos do WEBHOST1 principal local para o WEBHOST1 remoto. Repita a etapa para copiar a pasta de produtos de WEBHOST2 para WEBHOST2 remoto. E repita essa etapa para qualquer outra instância de computação do Oracle HTTP Server.

   Observação:

   Há um script de exemplo que você pode usar para copiar a pasta de produtos do Oracle HTTP Server do WEBHOST1 principal local para o WEBHOST1 remoto.

   Vá para Fazer Download do Código para fazer download do script.

4. Use rsync para copiar a pasta de configuração do Oracle HTTP Server do WEBHOST1 principal local para o WEBHOST1 remoto. Repita a etapa para copiar a pasta de configuração de WEBHOST2 para WEBHOST2 remoto. E repita essa etapa para qualquer outra instância de computação do Oracle HTTP Server.

   Observação:

   Há um script de exemplo que você pode usar para copiar a pasta de configuração do Oracle HTTP Server do WEBHOST1 principal local para o WEBHOST1 remoto.

   Vá para Fazer Download do Código para fazer download do script.

5. Copie o arquivo /etc/oraInst.loc dos hosts principais do Oracle HTTP Server e salve-o nos hosts secundários.
   Esse arquivo simplesmente contém a localização de oraInventory e não é alterado com o passar do tempo, portanto, essa cópia é uma ação única.
6. Se a pasta oraInventory estiver sob a pasta de produtos, ela será copiada junto com o Oracle home do Oracle HTTP Server. Se a pasta oraInventory estiver em um local diferente, certifique-se de também copiá-la para os hosts secundários.

A configuração e os binários do Oracle HTTP Server não são alterados com frequência. Após essa replicação inicial, você pode repetir a mesma replicação durante o ciclo de vida. Como alternativa, você pode manter manualmente a configuração do Oracle HTTP Server no principal e secundário implementando as alterações de configuração do Oracle HTTP Server em ambos os sites.

Preparar o OCI Load Balancer

Crie e configure o Balanceador de Carga do Oracle Cloud Infrastructure na nuvem.

Observação:

Você pode encontrar o código do Terraform para criar os recursos descritos nesta seção (o Balanceador de Carga do OCI, o certificado SSL, os conjuntos de backend e backends, as políticas de roteamento, os listeners e os conjuntos de regras) em Fazer Download do Código.

Provisionar o OCI Load Balancer

Para ser consistente com o site local principal, provisione um balanceador de carga em seu site secundário no Oracle Cloud Infrastructure (OCI) como ponto de entrada para o sistema.

1. Faça log-in na Console do OCI.
2. Selecione a região e o compartimento apropriados.
3. Navegue até Rede e, em seguida, Balanceadores de Carga. Clique em Criar Balanceador de Carga.
4. Selecione o tipo de Balanceador de Carga.
5. Forneça um nome para o balanceador de carga.
   Por exemplo: hyDRlbr.
6. Escolha o tipo de visibilidade (público ou privado) e a largura de banda que corresponda às suas necessidades.
   • Se o sistema for acessado de clientes externos pela internet, escolha a visibilidade pública. O balanceador de carga do OCI usará um IP público.
   • Se o sistema for acessado apenas de clientes internamente, você poderá escolher a visibilidade privada para provisionar o balanceador de carga apenas com um IP privado.
7. Selecione a VCN e a sub-rede apropriadas.
   Por exemplo, hydrvcn e webTierSubnet.
8. Não adicione nenhum back-end neste ponto.
9. Sair do listener padrão com valores padrão
10. Clique em Enviar.

Salve o IP do Balanceador de Carga do OCI (por exemplo, 100.100.100.10).

Fazer Upload dos Certificados

Faça upload dos certificados usados pelo balanceador de carga principal.

1. Na Console, clique em Balanceador de Carga, Certificados e Adicionar Certificado.
2. Faça upload do certificado SSL público e da chave privada do certificado que o Balanceador de Carga principal usa. Faça upload de certificados de CA (autoridade de certificação), se usado.
3. Informe um nome para o certificado e clique em Adicionar Certificado.
   O novo certificado é exibido na lista de certificados do Balanceador de Carga.
4. Se você usar mais de um certificado para acessar o sistema principal, repita essas etapas para fazer upload de todos os certificados.

Criar os Conjuntos de Backend

Um conjunto de backend é uma entidade lógica que contém uma lista de servidores de backend que executam os mesmos aplicativos. Ao definir um conjunto de backend, você deve especificar uma política de balanceamento de carga e um teste de verificação de integridade. Em seguida, você pode adicionar a lista de servidores de backend.

A configuração dos conjuntos de backend depende de você estar ou não usando o Oracle HTTP Server na frente dos hosts do WebLogic Server.

Se você estiver usando o Oracle HTTP Server, o Balanceador de Carga do Oracle Cloud Infrastructure (OCI) enviará as solicitações aos servidores HTTPS. Crie um conjunto de backend para cada porta exposta pelos servidores HTTPS. Por exemplo: crie um conjunto de backend para o listener do Oracle HTTP Server que forneça acesso aos aplicativos e outro conjunto de backend para o listener do Oracle HTTP Server que forneça acesso a cada Console de Administração do Oracle WebLogic Server.

Se você não estiver usando o Oracle HTTP Server, o Balanceador de Carga do OCI enviará as solicitações aos servidores WebLogic diretamente. Crie um conjunto de backend para cada Cluster do Oracle WebLogic Server e outro conjunto de backend para o Servidor Admin.

1. Faça log-in na Console do OCI.
2. Selecione a região e o compartimento apropriados.
3. No menu de navegação, clique em Rede e, em seguida, clique em Balanceadores de Carga.
4. Clique no balanceador de carga ao qual você deseja adicionar um backend.
5. Clique em Definições de Backend no menu Recursos e, em seguida, clique em Criar Conjunto de Backend.
6. Informe o seguinte na caixa de diálogo Criar Conjunto de Backend:
   1. Nome: Especifique um nome para o conjunto de backend.
      Os nomes de conjuntos de backend válidos só incluem caracteres alfanuméricos, traços e sublinhados.
   2. Política de distribuição de tráfego: Selecione Arredondamento Ponderado.
   3. Persistência de Sessão: Selecione Ativar persistência de cookie do balanceador de carga.
   4. Nome do Cookie: Informe um nome para o cookie usado para ativar a persistência de sessão.
   5. Atributos: Selecione Seguro.
   6. Verificação de Integridade: Selecione TCP para verificar a porta ou HTTP para verificar o caminho do URL (URI) e o código de resposta esperado.
      Veja a seguir exemplos de HTTP para Verificação de Integridade:
      • OHS_Admin_backendset: Caminho do URL /console, Código de Status 302
      • OHS_HTTP_backendset:
        • Caminho do URL /, Código de Status 200 (ou 404, dependendo da configuração do Oracle HTTP Server)
        • Caminho do URL /app1, Código de Status 200
7. Clique em Criar.

Se o seu Oracle HTTP Server atender em portas adicionais para outros serviços, crie um conjunto de backend para cada serviço de maneira semelhante.

Veja a seguir um exemplo dos conjuntos de backend quando você usa o Oracle HTTP Server.

Componente	Nome do Conjunto de Backend	Política de Distribuição de Tráfego	Persistência de Sessão	Nome do cookie (exemplo)	Atributo: seguro	Verificação de Integridade
Admin Server	OHS_Admin_backendset	Revezamento Ponderado	Ativar persistência de cookie do balanceador de carga	X-Oracle-LBR-ADMIN-Backendset	Desativado	TCP ou HTTP
Todos os componentes SOA Oracle SOA Suite Oracle Service Bus Oracle B2B Business Process Management Oracle Enterprise Scheduler (ESS) BAM (Business Activity Monitoring)	OHS_HTTP_backendset	Revezamento Ponderado	Ativar persistência de cookie do balanceador de carga	X-Oracle-LBR-OHS-HTTP-Backendset	Marcada	TCP ou HTTP
Oracle Web Services Manager	OHS_HTTP_internal_backendset	Revezamento Ponderado	Ativar persistência de cookie do balanceador de carga	X-Oracle-LBR-OHS-Internal-HTTP-Backendset	Desativado	TCP ou HTTP

Se o seu Oracle HTTP Server atender em portas adicionais para outros serviços, crie um conjunto de backend para cada serviço de maneira semelhante.

Veja a seguir um exemplo dos conjuntos de backend quando você não usa o Oracle HTTP Server.

Componente	Nome do Conjunto de Backend	Política de Distribuição de Tráfego	Persistência de Sessão	Nome do cookie (exemplo)	Atributo: seguro	Verificação da Situação
Todos os produtos (admin)	Admin_backendset	Revezamento Ponderado	Ativar persistência de cookie do balanceador de carga	X-Oracle-LBR-ADMIN-Backendset	Desmarcado	TCP ou HTTP
Oracle Web Services Manager	WSM_backendset	Revezamento Ponderado	Ativar persistência de cookie do balanceador de carga	X-Oracle-LBR-WSM-Backendset	Desmarcado	TCP ou HTTP
Oracle SOA Suite, Business Process Management e Oracle B2B	SOA_backendset	Revezamento Ponderado	Ativar persistência de cookie do balanceador de carga	X-Oracle-LBR-SOA-Backendset	Marcada	TCP ou HTTP
Oracle Service Bus	OSB_backendset	Revezamento Ponderado	Ativar persistência de cookie do balanceador	X-Oracle-LBR-OSB-Backendset	Marcada	TCP ou HTTP
Oracle Enterprise Scheduler (ESS)	ESS_backendset	Revezamento Ponderado	Ativar persistência de cookie do balanceador	X-Oracle-LBR-ESS-Backendset	Marcada	TCP ou HTTP
BAM (Business Activity Monitoring)	BAM_backendset	Revezamento Ponderado	Ativar persistência de cookie do balanceador	X-Oracle-LBR-BAM-Backendset	Marcada	TCP ou HTTP

Se você tiver clusters WebLogic adicionais, crie um conjunto de backend para cada cluster de maneira semelhante.

Defina os Backends para Cada Conjunto de Backend

Defina os backends para cada conjunto de backend no Balanceador de Carga do Oracle Cloud Infrastructure (OCI).

Se você estiver usando o Oracle HTTP Server, adicione os nós do Oracle HTTP Server e as portas apropriadas como backends em cada conjunto de backend.

Se você não estiver usando o Oracle HTTP Server, adicione os nós do Oracle WebLogic Server e as portas apropriadas como backends em cada conjunto de backend.

1. Na Console, selecione um Conjunto de Backend. Clique em Backends e, em seguida, clique em Adicionar Backends.
2. Informe o endereço IP e a porta do servidor que é o backend.

A tabela mostra os conjuntos de backend criados no exemplo deste documento ao usar o Oracle HTTP Server:

Nome do Conjunto de Backend	Backends
OHS_Admin_backendset	Instâncias de Computação: hydrohs1, a porta do Oracle HTTP Server para o listener de consoles (como 7001) hydrohs2, a porta do Oracle HTTP Server para o listener de consoles (como 7001)
OHS_HTTP_backendset	Instâncias de Computação: hydrohs1, a porta do Oracle HTTP Server para o listener HTTP (como 8890) hydrohs2, a porta do Oracle HTTP Server para o listener HTTP (como 8890)
OHS_HTTP_internal_backendset	Instâncias de Computação: hydrohs1, a porta do Oracle HTTP Server para o listener interno HTTP (como 8891) hydrohs2, a porta do Oracle HTTP Server para o listener interno HTTP (como 8891)

A tabela mostra os conjuntos de backend criados no exemplo deste documento quando NÃO usa o Oracle HTTP Server:

Nome do Conjunto de Backend	Backends
Admin_backendset	Endereço IP: O IP virtual do servidor Admin criado anteriormente, porta do servidor Admin (7001)
WSM_backendset	Instâncias de Computação: hydrsoa1, porta WSM server1 (7010) hydrsoa2, porta WSM server2 (7010)
SOA_backendset	Instâncias de Computação: hydrsoa1, porta SOA server1 (8001) hydrsoa2, porta SOA server2 (8001)
OSB_backendset	Instâncias do Serviço Compute: hydrsoa1, porta server1 do OSB (8010) hydrsoa2, porta server2 do OSB (8010)
ESS_backendset	Instâncias do Serviço Compute: hydrsoa1, porta server1 ESS (8021) hydrsoa2, porta server2 ESS (8021)
BAM_backendset	Instâncias do Serviço Compute: hydrsoa1, porta BAM server1 (9001) hydrsoa2, porta BAM server2 (9001)

Definir as Políticas de Roteamento e Configurar as Regras

As políticas de roteamento são usadas para despachar as solicitações recebidas para o conjunto de backend correto. Por exemplo, uma solicitação para /console é despachada para o conjunto de backend Admin e uma solicitação para /app1 é despachada para o conjunto de backend do Cluster em que app1 está sendo executado.

Se você estiver usando o Oracle HTTP Server, normalmente definirá as rotas (como /app1, /app2, /console etc.) na configuração do Oracle HTTP Server. Nesse caso, você não precisa definir as políticas e regras de roteamento no Balanceador de Carga do Oracle Cloud Infrastructure (OCI).

Se você não estiver usando o Oracle HTTP Server, será necessário definir as políticas e as regras de roteamento no Balanceador de Carga do OCI para despachar as solicitações para o conjunto de backend apropriado.

1. Na Console do Oracle Cloud Infrastructure, clique no Balanceador de Carga.
2. Clique em Políticas de Roteamento e, em seguida, clique em Criar Políticas de Roteamento para definir as políticas.
   As políticas de roteamento são adicionadas aos listeners do Balanceador de Carga posteriormente.
3. Informe um nome para a política de roteamento (conjunto de regras).
   Por exemplo, Admin_Rules.
4. Para criar regras na política de roteamento, informe um nome para a regra.
   Por exemplo, Admin_routerule.
5. Defina as condições da regra para rotear solicitações para diferentes conjuntos de backend. Selecione Se Houver Correspondência, Tipo de Condição: Caminho, Operador: Começa com e informe uma String de URL.
   Por exemplo, Se houver alguma correspondência, Caminho, Começa com, /console.
6. Selecione o Conjunto de Backend no menu para configurar a ação.
   Por exemplo, OHS_Admin_backendset.

A tabela mostra as políticas e regras de roteamento no Balanceador de Carga do Oracle Cloud Infrastructure criado seguindo o exemplo neste documento quando o Oracle HTTP Server não é usado.

Componente	Nome da Política de Roteamento	Regra	Condições: Se Qualquer Caminho de Correspondência começar com	Ação: Rotear para Conjunto de Backend
Todos os produtos (admin)	Admin_Rules	Admin_routerule	/console /em	Admin_backendset
Oracle Service Bus (admin)	Admin_Rules	Admin_routerule	/sbconsole /servicebus	Admin_backendset
Oracle Web Services Manager	Internal_Rules	WSM_routerule	/wsm-pm	WSM_backendset
Oracle Service Bus	SOA_Rules	OSB_routerule	/sbinspection.wsil /sbresource /osb /alsb	OSB_backendset
Oracle SOA Suite	SOA_Rules	SOA_routerule	/soa-infra /integration /sdpmessaging /userprefs-ui /DefaultToDoTaskFlow /workflow /ADFAttachmentHelper /soa/composer (*) mais alias personalizado pode ser necessário para tarefas personalizadas	SOA_backendset
Gerenciamento de Processos de Negócios	SOA_Rules	SOA_routerule	/bpm/composer /bpm/workspace /bpm/casemgmt	SOA_backendset
Oracle Enterprise Scheduler (ESS)	SOA_Rules	ESS_routerule	/ess /EssHealthCheck /ess-async /ess-wsjob	ESS_backenset
Monitoramento de Atividade de Negócios (BAM)	SOA_Rules	BAM_routerule	/bam /composer /OracleBAMWS /oracle/bam	BAM_backendset
Oracle B2B	SOA_Rules	B2B_routerule	/b2bconsole /b2b/services /b2b/httpreceiver	SOA_backendset

Você pode criar quantas políticas de roteamento, regras e condições precisar para seu ambiente.

Criar os Listeneres

Crie os listeners para cada combinação de nome e porta de front-end usada para acessar o sistema. Você deve usar os mesmos nomes de host (nomes front-end virtuais) e portas usados pelo balanceador de carga principal.

1. Adicione o nome do host front-end virtual como nome do host no Balanceador de Carga do Oracle Cloud Infrastructure.
2. Crie os listeners.

A tabela a seguir é um resumo dos listeners criados no exemplo deste documento e seu protocolo, porta, conjuntos de backend, política de roteamento, nome do host e uso de SSL associados. Isso é apenas um exemplo de referência. Se seu sistema usar nomes de host front-end adicionais, portas ou protocolos no sistema principal do Oracle WebLogic Server, você deverá criar os listeners e nomes de host correspondentes de acordo com suas necessidades. Por exemplo, se você usar um front-end alternativo para acessar a Console do Oracle WebLogic Server e a Console do Oracle Enterprise Manager.

Listener	Protocolo	Porta	Conjunto de Backend	Política de Roteamento	Nome do Host	Usar SSL
Admin_listener	HTTP	7001	OHS_Admin_backendset (se o Oracle HTTP Server for usado) Admin_backendset (se o Oracle HTTP Server não for usado)	Admin_Rules	mysoa.example.com	Não
HTTPS_listener	HTTPS	443	OHS_HTTP_backendset (se o Oracle HTTP Server for usado) SOA_backendset (se o Oracle HTTP Server não for usado)	SOA_Rules	mysoa.example.com	Sim
HTTP_listener	HTTP	80	N/D*	NÃO APLICÁVEL	mysoa.example.com	Não
Internal_listener	HTTP	8888	OHS_HTTP_internal_backendset (se o Oracle HTTP Server for usado) WSM_backendset (se o Oracle HTTP Server não for usado)	Internal_Rules	mysoa.example.com	Não

* O HTTP_listener neste exemplo é usado apenas para redirecionar solicitações para o HTTPS_listener (HTTPS). O backend designado a ele não será usado. Mas, como é obrigatório fornecer um, forneça um que não tenha SSL marcado (use um conjunto de backend vazio padrão).

Criar o Conjunto de Regras para Cabeçalhos SSL

Crie um conjunto de regras para cabeçalhos SSL no Balanceador de Carga do Oracle Cloud Infrastructure (OCI) e associe-o ao listener HTTPS.

Assim como no site principal, o Balanceador de Carga do OCI encerra o SSL e a comunicação entre o Balanceador de Carga e o servidor de backend é executada por meio do protocolo HTTP. Para que isso funcione corretamente, adicione cabeçalhos de solicitação ao Balanceador de Carga do OCI. Esses cabeçalhos são adicionados às solicitações do cliente que vêm para o listener HTTPS, antes de serem despachados para o back-end WebLogic. Os cabeçalhos informam WebLogic que a comunicação do cliente final com o Balanceador de Carga usou HTTPS. Dessa forma, qualquer URL que WebLogic construa dinamicamente será gerado corretamente usando HTTPS.

1. Selecione o Balanceador de Carga na Console. Clique em Conjuntos de Regras e em Criar Conjunto de Regras.
2. Forneça um nome para a regra.
   Por exemplo, SSLHeaders.
3. Marque Especificar Regras de Cabeçalho de Solicitação e adicione as seguintes ações:

   Ação	Cabeçalho	Valor
   Adicionar Cabeçalho de Solicitação	is_ssl	ssl
   Adicionar Cabeçalho de Solicitação	WL-Proxy-SSL	Verdadeiro

4. Clique em Criar.
5. Clique em Balanceador de Carga e, em seguida, clique em Listener. Edite o listener que usa HTTPS para associar a regra ao listener HTTPS.
6. Clique em +Additional Conjunto de Regras e, em seguida, selecione o conjunto de regras SSLHeaders.

Criar o Conjunto de Regras para Redirecionar o Protocolo HTTP para HTTPS

Crie uma regra de redirecionamento e associe-a ao HTTP_listener para redirecionar a porta 80 para a porta 443. Para a topologia EDG, todas as solicitações que atingem a porta 80 (HTTP) no Balanceador de Carga devem ser redirecionadas para a porta 443 (HTTPS).

1. Na Console, selecione o Balanceador de Carga.
2. Clique em Conjuntos de Regras e em Criar Conjunto de Regras.
3. Informe um nome para a regra.
   Por exemplo, HTTP_to_HTTPS_redirect.
4. Marque Especificar Regras de Redirecionamento de URL e adicione as seguintes ações
   • Caminho de origem: /
   • Tipo de Correspondência: Forçar Correspondência de Prefixo Mais Longo
   • Redirecionar para:
   • Protocolo: HTTPS
   • Host: {host} (deixe o valor padrão)
   • Porta: 443
   • Caminho: /{path} (deixe o valor padrão)
   • Consulta: ?{query} (deixe o valor padrão)
   • Código de Resposta: 301 - Movido Permanentemente
5. Clique em Balanceador de Carga e, em seguida, em Listener. Edite o listener que usa a porta HTTP 80 para associá-lo ao listener HTTP.
6. Clique em +Additional Conjunto de Regras e selecione a regra HTTP_to_HTTPS_redirect.

Adicionar o Nome Front-end Virtual e o IP às Instâncias do Serviço SOA Compute

Em uma topologia de recuperação de desastres, os clientes devem acessar o sistema usando um FQDN front-end (geralmente conhecido como nome de front-end virtual ou URL personalizado) que é independente do data center. Esse nome de front-end virtual deve ser resolvido para o endereço IP do Balanceador de Carga do site ativo (principal) atual.

O sistema primário já deve estar usando um nome virtual front-end que seja resolvido pelo DNS com o IP do Balanceador de Carga principal. No entanto, os hosts do Oracle SOA Suite de cada site devem sempre resolver o nome front-end com seu balanceador de carga local, independentemente da resolução voltada para o cliente com DNS. Para isso, o nome front-end virtual é adicionado ao arquivo /etc/hosts com o endereço IP apropriado em cada site. Você também pode conseguir isso usando servidores DNS diferentes em cada site. Nesse caso, o servidor DNS local resolveria o nome front-end com o IP do balanceador de carga apropriado em cada site.

Usar Arquivos /etc/hosts

O arquivo /etc/hosts dos hosts principal e secundário do Oracle WebLogic Server não deve ser alterado quando houver um switchover ou failover. Os hosts do Oracle WebLogic Server sempre resolverão o nome do front-end virtual com seu IP front-end. A atualização de DNS necessária durante os procedimentos de switchover e failover é executada nos arquivos DNS ou host usados pelos clientes do Oracle WebLogic Server.

1. Como usuário raiz, edite o arquivo /etc/oci-hostname.conf nas instâncias de computação secundárias do Oracle WebLogic Server for Oracle Cloud Infrastructure e mapeie o nome front-end para o IP do Balanceador de Carga do Oracle Cloud Infrastructure (OCI).

   Veja a seguir um exemplo do arquivo /etc/hosts da instância de computação secundária do Oracle WebLogic Server for OCI, incluindo a entrada do nome do front-end.

   #################################
   # ALIASES in OCI 
   #################################
   100.70.10.20   hydrsoa-vip.midTiersubnet.hydrvcn.oraclevcn.com      hydrsoa-vip       ADMINVHN.example.com    ADMINVHN    
   100.70.10.13   hydrsoa1.midTiersubnet.hydrvcn.oraclevcn.com         hydrsoa1          SOAHOST1.example.com    SOAHOST1
   100.70.10.14   hydrsoa2.midTiersubnet.hydrvcn.oraclevcn.com         hydrsoa2          SOAHOST2.example.com    SOAHOST2
   
   # Front-end name (resolved to secondary OCI LBR IP)
   100.100.100.10    mysoa.example.com

2. Se ainda não tiver sido feito, siga as mesmas etapas nos hosts principais do Oracle WebLogic Server. O nome front-end deve apontar para o IP do balanceador de carga principal.
   Veja a seguir um exemplo do arquivo /etc/hosts do host principal do Oracle WebLogic Server local, incluindo a entrada do nome do front-end.

   #################################
   # ALIASES in on-prem 
   #################################
   10.10.10.20   host-vip1.myopnetwork.com    host-vip1         ADMINVHN.example.com   ADMINVHN    
   10.10.10.13   host3.myopnnetwork.com       host3             SOAHOST1.example.com   SOAHOST1
   10.10.10.14   host4.myopnnetwork.com       host4             SOAHOST2.example.com   SOAHOST2
   
   # Front-end name (resolved to primary Load Balancer IP)
   10.10.10.100    mysoa.example.com

3. Se o sistema Oracle WebLogic Server usar mais nomes front-end virtuais, adicione-os ao arquivo seguindo a mesma regra.

Usar o Sistema de Nomes de Domínio (DNS)

Este modo é válido quando servidores DNS separados são usados no local principal e no secundário no Oracle Cloud Infrastructure (OCI). Caso contrário, ele poderá causar conflitos na resolução de nomes.

Se você estiver seguindo essa abordagem, poderá adicionar o nome front-end (apontando para o IP do balanceador de carga secundário) ao serviço de DNS usado pelas camadas intermediárias secundárias. Em principal, espera-se que o nome do front-end já esteja resolvido, apontando para o IP do balanceador de carga principal.

Na instância principal, espera-se que o nome do front-end já tenha sido resolvido, apontando para o IP do balanceador de carga principal.