Compreender a Arquitetura do Oracle Siebel CRM no Oracle Cloud Infrastructure

Você pode planejar a arquitetura para implantar o Oracle Siebel CRM em vários domínios de disponibilidade para garantir alta disponibilidade. A alta disponibilidade de um aplicativo dentro de um domínio de disponibilidade pode ser obtida colocando instâncias de aplicativo em domínios de falha separados.

Arquitetura para Implantar o Siebel 19.x e versões posteriores para Alta Disponibilidade em uma Única Região em Vários Domínios de Disponibilidade

Essa arquitetura mostra como implantar o Siebel 19.x e versões posteriores para alta disponibilidade em uma única região em vários domínios de disponibilidade (ADs).

Os clientes interessados em implantar em nossas regiões de domínio de disponibilidade múltipla (Phoenix, Ashburn, Londres, Frankfurt) têm a opção de recuperação de desastres em ADs em uma única região.

Descrição da ilustração hasing-reg-multi-ad-siebel-19-20-21.png

ha-sing-reg-multi-ad-siebel-19-20-21.zip

• Sub-redes Regionais entre ADs (1): As sub-redes regionais abrangem toda a região, fornecendo benefícios como proteção contra falha de rede do AD, implantação e gerenciamento simplificados de serviços Siebel. Nesta arquitetura, os bastion hosts, balanceadores de carga e servidores de camada de aplicativo em ambos os ADs estão no estado ativo.
• Balanceamento de carga entre ADs (2): O Balanceamento de Carga Público distribui o tráfego entre os servidores em todos os ADs configurados, fornecendo proteção contra uma falha do AD.
• Componentes do Siebel AI Server ativo-ativo entre ADs (3): Ao agrupar serviços suportados entre ADs, você pode obter proteção contra qualquer falha imprevista em um único AD.
• Componentes do Servidor Siebel Ativos-Ativos em ADs (4): Ao agrupar serviços suportados em ADs, você pode obter proteção contra qualquer falha imprevista em um único AD. O GWY e o Siebel File System são mostrados como Ativos-Passivos nos ADs.
• Database DR entre Domínios de Disponibilidade (5): O uso do Data Guard ou do Active Data Guard depende do seu caso de uso e da edição do banco de dados. O Active Data Guard requer o Enterprise Edition – Extreme Performance.

Arquitetura para Implantação do Siebel 19.x e versões posteriores para Recuperação de Desastres em Várias Regiões

Essa arquitetura mostra como implantar o Siebel 19.x e versões posteriores para recuperação de desastres (DR) em várias regiões.

Você pode obter DR verdadeiro em várias regiões no caso improvável de uma região ficar inativa.

Observação:

Essa arquitetura de referência abrange o caso mais robusto com clusterização de serviços suportados em ADs dentro da região principal, mas a DR pode ser obtida em regiões com um único AD. Isso é importante observar, pois a maioria das nossas novas regiões da OCI lançadas serão regiões com um único AD.

Descrição da ilustração dr-multi-reg-19-20-21.png

dr-multi-reg-19-20-21.zip

• Pareamento de VCN entre Regiões: As VCNs podem se conectar entre regiões em uma tenancy ou até mesmo entre tenancies. A conectividade é obtida usando o backbone interno da Oracle entre regiões. Se você tiver dois aplicativos em execução em dois ADs diferentes, o pareamento de VCN permitirá que eles se comuniquem internamente.
• Componentes Ativos-Ativos entre ADs: A clusterização de serviços suportados entre ADs fornece proteção contra uma falha do AD.
• Balanceamento de carga entre ADs: O Balanceamento de Carga Público distribui o tráfego entre os servidores Siebel em todos os ADs configurados, fornecendo proteção contra um AD
• Distribuir Componentes do Servidor de Aplicativos Ativo-Passivo entre Regiões: Se você estiver usando Ativo-Passivo para sincronizar servidores de aplicativos entre ADs, use rsync.
• Sub-redes regionais entre ADs: As sub-redes regionais abrangem toda a região, fornecendo resiliência contra falha de rede do AD e implantação e gerenciamento simplificados de serviços Siebel.
• Database DR entre ADs: O uso do Data Guard ou do Active Data Guard depende do seu caso de uso e da edição do banco de dados. O Active Data Guard requer o Enterprise Edition – Extreme Performance.
• Sincronização de armazenamento entre ADs: Os backups de volume em blocos entre regiões podem ser feitos usando a console, a CLI, SDKs ou APIs REST. A cópia de backups de volume em blocos para outra região em intervalos regulares facilita a reconstrução de aplicativos e dados na região de destino se um desastre geral ocorrer na região de origem. Você também pode migrar e expandir facilmente aplicativos para outra região. Com a cópia entre regiões do Object Storage, os dados copiam de forma assíncrona objetos entre buckets na mesma região ou para buckets em outras 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. É criado um grupo de segurança de rede separado para cada camada.

Use listas de segurança para permitir o tráfego entre diferentes camadas e entre o bastion host e os 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 é aplicado no nível da 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 de aplicativo e banco de dados pela internet. Use um grupo de segurança de rede personalizado para impedir o acesso às instâncias de aplicativo e banco de dados pela internet e permitir o acesso ao banco de dados e aos hosts de aplicativos na porta 22 do bastion host para fins de administração. Não ative o acesso SSH às instâncias de aplicativo e banco de dados pela internet, mas você pode permitir o acesso SSH a essas instâncias pela sub-rede que contém o bastion host.

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

Lista de Segurança do Bastion Host

A lista de segurança do bastion permite que o bastion host seja acessível pela Internet pública na porta 22.

• Para permitir o tráfego SSH da rede local para o bastion host pela Internet:

  Entrada com monitoramento de estado: permita tráfego TCP do CIDR de origem 0.0.0.0/0 e de 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 bastion host a ser acessível pela Internet na porta 22 somente do seu data center, em vez da Internet pública (0.0.0.0/0). Para fazer 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 o tráfego SSH do bastion host para instâncias do Oracle Cloud Infrastructure Compute:

  Saída com monitoramento de estado: permite tráfego TCP para o CIDR de destino 0.0.0.0/0 de todas as portas de origem para a porta de destino 22 (SSH).

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

Lista de Segurança para as Instâncias do Oracle Cloud Infrastructure Load Balancing

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 (0.0.0.0/0) para as instâncias do balanceador de carga.

• Para permitir o tráfego da Internet para o balanceador de carga:

  Entrada com monitoramento de estado: permita tráfego TCP do CIDR (Internet) de origem 0.0.0.0/0 e de todas as portas de origem para a porta de destino 80 (HTTP) ou 443 (HTTPS).

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

• Para permitir o tráfego da rede local para o balanceador de carga:

  Entrada com monitoramento de estado: Permitir tráfego TCP do bloco CIDR da rede local e de todas as portas de origem para a porta de destino 80 (HTTP) ou 443 (HTTPS)

  Source Type = CIDR, Source CIDR = <CIDR block for onpremises network>, IP Protocol = TCP, Source Port Range = All, Destination port range = 80 or 443

• Para permitir o tráfego das camadas do balanceador de carga para os servidores de aplicativos:

  Saída com monitoramento de estado: Permitir tráfego TCP para o 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 for application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = All

Lista de segurança para Siebel Web Servers

Crie as listas de segurança a seguir para permitir o tráfego das instâncias do balanceador de carga e do servidor bastion para os servidores Web Siebel. O tráfego recebido das instâncias do balanceador de carga é encaminhado para os servidores de aplicativos Siebel na camada de aplicativos.

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

  Entrada com monitoramento de estado: Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

• Para permitir o tráfego da camada do balanceador de carga para a camada do aplicativo:

  Entrada com monitoramento de estado: Source Type = CIDR, Source CIDR = <CIDR block of load balancer subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 80 or 443

• Para permitir o tráfego dos servidores Web Siebel para os servidores Siebel na camada de aplicativos:

  Saída com monitoramento de estado: Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = All

Lista de Segurança da Camada de Aplicativos

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

  Entrada com monitoramento de estado: Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

• Para permitir o tráfego dos servidores Siebel para o Siebel Gateway Name Server:

  Entrada com monitoramento de estado: Source Type = CIDR, Source CIDR = <CIDR block of Siebel application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 2320

• Para permitir o tráfego dos servidores Web Siebel para os servidores de aplicativos Siebel:

  Entrada com monitoramento de estado: Source Type = CIDR, Source CIDR = <CIDR block of Siebel web subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 2321

• Para permitir tráfego de saída:

  Saída com monitoramento de estado: Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = All

Lista de Segurança da Camada de Banco de Dados

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

  Entrada com monitoramento de estado: Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

• Para permitir o tráfego dos servidores de aplicativos Siebel para a camada de banco de dados:

  Entrada com monitoramento de estado: Source Type = CIDR, Source CIDR = <CIDR block of siebel application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 1521

• Para permitir tráfego de saída:

  Saída com monitoramento de estado: Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = All