Saiba Mais Sobre o Design de Rede

Os componentes de infraestrutura de rede do OCI, como VCNs, sub-redes e gateways, que são criados sem planejamento adequado usando os parâmetros padrão podem levar a problemas após a implantação que podem ser difíceis de resolver. Um design de rede bem planejado ajuda a configurar uma implementação bem-sucedida e facilita o uso da sua equipe e organização.

Execute seu projeto de rede cedo

Projetar completamente sua rede antes da implantação permite que você detecte problemas antecipadamente e remova barreiras para uma implantação bem-sucedida. Embora seja possível alterar alguns elementos de design de rede da OCI posteriormente, pode exigir um esforço significativo e pode interromper o fluxo de negócios temporariamente.

A Oracle recomenda o seguinte para seu design de rede do OCI:

1. Planeje o tempo apropriado e aloque recursos suficientes em seu plano de projeto para projetar adequadamente sua rede do OCI.
2. Inclua minimamente o layout, a topologia, o dimensionamento de VCNs e sub-redes, o Serviço de Nomes de Domínio (DNS) e qualquer conectividade de rede externa com CSPs locais ou outros.
3. Considere trabalhar com sua equipe de contas da Oracle para ver se a Oracle pode fornecer especialistas em rede da OCI para ajudá-lo.

Veja a seguir um exemplo de diagrama de design de rede.

Descrição da ilustração vcn-network-design-example.png

Dica:

Procure arquiteturas de referência relevantes para sua implantação específica usar como ponto de partida. Por exemplo, a Oracle tem muitas arquiteturas de referência para implantações comuns do Oracle OCI, como Oracle E-Business Suite, Siebel e ExaCS no Oracle Architecture Center.

Considere um Design de VCN Hub e Spoke

A melhor prática e recomendação da Oracle para a maioria das implantações do OCI é usar um design de várias VCN em uma topologia hub e spoke utilizando o DRG para conectividade.

Veja a seguir os benefícios de um design de hub e spoke de várias VCN usando o DRG:

• Isolar e segmentar ambientes diferentes.
• Forneça serviços comuns dentro da VCN hub que todas as VCNs spoke possam compartilhar, como servidor de logs, DNS e compartilhamento de arquivos.
• Dimensione sua rede facilmente, pois o DRG permite que você conecte até 300 VCNs. Depois de ter um design de VCN hub e spoke, é fácil adicionar mais VCNs.
• Coloque appliances de segurança de rede, como firewalls, na VCN hub, para inspecionar o tráfego destinado ou proveniente das VCNs spoke.

O diagrama a seguir mostra um exemplo de uso de uma arquitetura de rede hub e spoke:

Descrição da ilustração hub-and-spoke-topology.png

A Oracle recomenda o seguinte:

• Decida como e onde você pode segmentar diferentes ambientes de rede e considere colocar cada um em sua própria VCN. Veja a seguir exemplos comuns de clientes para usar VCNs separadas para ambientes:
  • Ambientes de produção e não produção
  • Clientes internos ou externos
• Se você tiver uma implantação de OCI muito simples ou pequena, como uma Prova de Conceito (POC), e não precisar de nenhum dos benefícios discutidos aqui, usar uma única VCN será uma boa abordagem. Mesmo com uma única VCN, você sempre pode colocar um ambiente em outra VCN no futuro para aproveitar essas recomendações.

Usar Convenções de Nomenclatura Padrão do OCI

Ao provisionar os recursos de rede necessários no OCI, como VCNs, sub-redes, listas de segurança e DRGs (Dynamic Routing Gateways), você será solicitado a informar um nome de recurso. O uso de uma convenção de nomenclatura padrão para seus recursos do OCI ajuda você e outros usuários do OCI a entender a finalidade e a localização dos recursos e também indica como um recurso se diferencia de outros.

Alguns desses nomes de recursos podem ser alterados posteriormente; no entanto, alguns não podem, como label DNS. Outros, como o nome da VCN, devem ser alterados usando a CLI (interface de linha de comando).

A Oracle recomenda o seguinte:

1. Use um acrônimo descritivo em algum lugar no nome para descrever a finalidade de um recurso. Por exemplo:
   • vcn em algum lugar no nome da VCN (Nome da VCN: vcn-prod-ashburn)
   • drg em algum lugar no nome do DRG (Nome do DRG: drg-ashburn)
   • sl em algum lugar no nome da sua Lista de Segurança (Nome da Lista de Segurança: web-sn-sl)
2. Certifique-se de que a convenção de nomenclatura de recursos de rede do OCI faça parte da convenção geral de nomenclatura de recursos do OCI.
3. Considere o uso de tags para adicionar informações de metadados aos recursos.

Projete um DNS Híbrido com o DNS Privado da OCI

O comportamento padrão do OCI se limita a executar a resolução interna de DNS para a VCN usando oraclevcn.com como domínio padrão. Isso pode levar a problemas de conectividade posteriormente porque você não pode resolver os nomes de DNS para recursos em outras VCNs ou ambientes locais.

O serviço DNS Privado do OCI fornece a capacidade de resolver perfeitamente o DNS entre o OCI e a infraestrutura local:

• Crie e mantenha domínios e registros de DNS personalizados em suas VCNs (como oci.customer.com).
• Integre a resolução de DNS entre VCNs, com DNS local e outros ambientes, como CSPs ou DNSs de parceiros confiáveis.

A Oracle recomenda o seguinte:

• Inclua o DNS como parte do seu design de rede inicial e envolva seus administradores de DNS.
• Considere todos os ambientes em que você deseja resolução perfeita de nomes de DNS (para ou de ambientes locais, VCNs do OCI, outros CSPs etc.) e use o DNS privado do OCI para ativar uma solução de DNS híbrido.
• Considere as advertências cedo e determine a direção que deseja seguir. Decida se deseja usar o nome de domínio oraclevcn.com padrão ou um nome de domínio personalizado.

O diagrama a seguir mostra um exemplo de arquitetura com nomes de domínio personalizados usando um resolvedor de DNS privado para resolução de recursos internos locais com nomes de domínio personalizados:

Descrição da ilustração architecture-deploy-private-dns.png

Dica:

Quando você usa um nome de domínio personalizado do OCI, o gerenciamento das zonas e dos registros personalizados é manual. O oraclevcn.com padrão é automático.

Decidir os Tipos de Sub-rede Antes do Provisionamento

Os CIDRs da VCN devem ser divididos em uma ou mais sub-redes para organizar recursos. As sub-redes podem ser regionais ou específicas do Domínio de Disponibilidade (AD) e também podem ser sub-redes públicas ou privadas.

As decisões sobre sub-redes regionais versus específicas do AD e sub-redes públicas versus privadas não podem ser alteradas posteriormente. Certifique-se de que eles estejam corretos ao provisioná-los inicialmente para minimizar a interrupção e a complexidade em um estágio posterior.

A Oracle recomenda o seguinte:

• Determine se você precisa de sub-redes públicas ou privadas antes de criá-las. Considere possíveis fluxos de tráfego e onde o tráfego é originado ou destinado.
• Coloque recursos que tenham um requisito específico para conectividade de internet de entrada em sub-redes públicas e todos os outros recursos em sub-redes privadas.
• Provisione sub-redes regionais, a menos que você tenha um requisito específico que exija o uso de sub-redes específicas do AD.

Dica:

Para fazer alterações posteriormente, encerre as sub-redes e, em seguida, reprovisione-as. Você também deve encerrar os recursos implantados nas sub-redes e, em seguida, reprovisionar os recursos nas novas sub-redes.

Projete e dimensione suas sub-redes

Projete e dimensione suas sub-redes para atender aos requisitos atuais e futuros. O dimensionamento adequado de VCNs e sub-redes durante o design ajudará você a:

• Prepare-se para crescimento e expansão futuros
• Simplifique sua alocação de IP usando espaço de endereçamento IP contíguo e resumível

A Oracle recomenda o seguinte:

• Antes de criar uma VCN, determine o número de blocos CIDR necessários e o tamanho de cada bloco com base no número de recursos e sub-redes que você planeja implantar na VCN.
• Certifique-se de permitir alguma quantidade de crescimento futuro dentro das sub-redes e das VCNs.
• De preferência, incline-se para criar um CIDR maior do que muito pequeno.
• Você pode adicionar até cinco CIDRs a uma VCN; no entanto, adicionar mais posteriormente para acomodar o crescimento pode resultar em CIDRs não contíguos, dependendo da alocação do seu endereço IP.
  • Por exemplo, você alocou 10.0.0.0/24 para uma VCN para começar a testar uma carga de trabalho. Após testes bem-sucedidos, se você quiser expandir a carga de trabalho para mais VMs, ela precisará de mais IPs e sub-redes. No entanto, o próximo bloco IP 10.0.1.0/24 foi alocado na sua ferramenta de endereço IP para outra finalidade. Como resultado, você é forçado a adicionar um CIDR não contíguo à VCN.
• Se possível, use blocos CIDR que estejam dentro do espaço de endereço IP privado RFC 1918 padrão.
• Evite usar o espaço de endereço IP 169.254.0.0/16. Muitos provedores, incluindo a Oracle, usam o mesmo espaço IP em sua rede e isso pode causar problemas.
• Selecione blocos CIDR exclusivos que não se sobreponham a nenhuma outra rede (no OCI, seus data centers locais ou outro CSP).
• Ao projetar as sub-redes, considere seus requisitos de fluxo de tráfego e segurança. Anexe todos os recursos dentro de uma camada ou função específica à mesma sub-rede.

Usar Tabelas de Roteamento Personalizadas e Listas de Segurança para Cada Sub-rede

Ao provisionar sub-redes, você será solicitado a escolher uma tabela de roteamento da VCN e uma lista de segurança a ser usada com cada sub-rede.

O OCI fornece uma tabela de roteamento padrão e uma lista de segurança padrão que, se usada, é compartilhada com todas as sub-redes associadas a elas. Usar as opções padrão para elas é bom para uma implantação simples ou para começar, mas não é uma abordagem recomendada para um design de produção que inclua várias sub-redes. O uso de tabelas de roteamento da VCN e listas de segurança específicas de cada sub-rede permite manter o roteamento granular e o controle de segurança para as sub-redes individuais, em vez de fazê-las compartilhar esses recursos.

Por exemplo:

• Talvez você queira que uma sub-rede privada tenha uma rota padrão para um gateway NAT e uma sub-rede pública tenha uma rota padrão para um gateway de internet que exigiria tabelas de roteamento de VCN separadas.
• Talvez você queira permitir um fluxo de tráfego específico para uma sub-rede, mas não para outra, o que exigiria listas de segurança separadas

A Oracle recomenda o seguinte:

• Criar e associar uma tabela de roteamento de VCN exclusiva para cada sub-rede
• Criar e associar uma lista de segurança exclusiva para cada sub-rede

Dica:

Crie e associe essas tabelas de roteamento e listas de segurança exclusivas da VCN quando provisionar as sub-redes, pois será mais difícil alterar as padrão posteriormente.