Projetando um plano de endereçamento para um VPC

A primeira etapa para projetar seu IBM Cloud® Virtual Private Cloud é projetar seu plano de endereçamento.

Um plano de endereçamento projetado de maneira adequada tem dois objetivos:

Ele atende aos requisitos de comunicação de instâncias de VPC.
Ele mantém a flexibilidade para o crescimento futuro.

Este documento fornece um exemplo de design do plano de endereçamento para um aplicativo da web com três camadas, em que cada camada é suportada por múltiplas zonas.

Embora cada IBM Cloud VPC seja implementado em uma região específica, a VPC pode abranger todas as zonas dentro dessa região. A IBM Cloud VPC define um prefixo de endereço padrão para cada zona. Os prefixos de endereço permitem a comunicação entre as instâncias do VPC em diferentes zonas.

As mesmas etapas de design estão envolvidas, não importa se o aplicativo está completamente contido na nuvem ou se partes do aplicativo estão em execução em outro local.

Ao criar instâncias de VPC que você pretende interconectar usando o IBM Cloud Transit Gateway, evite selecionar prefixos de endereço padrão. Crie suas instâncias de VPC com prefixos sem sobreposição para conectividade bem-sucedida

Quando você cria instâncias de VPC que também pretende interconectar com sua infraestrutura clássica IBM Cloud usando o IBM Cloud Transit Gateway, não use endereços IP em suas instâncias nos blocos 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15 e 10.254.0.0/16. Além disso, evite endereços IP de suas sub-redes de infraestrutura clássicas.

Para obter mais informações sobre como projetar suas instâncias de VPC para uso com o IBM Cloud Transit Gateway, consulte Planejamento para o IBM Cloud Transit Gateway.

Suposições e considerações de design

Ao projetar o plano de endereçamento para um aplicativo, a principal consideração é manter os blocos CIDR que são usados para a criação de sub-redes em uma zona única o mais contíguos possível. Ao fazer isso, é possível resumi-los em um único prefixo de endereço, deixando espaço para um crescimento futuro.

Outra consideração é o número de endereços disponíveis que uma sub-rede pode precisar para o dimensionamento horizontal. A Tabela 1 lista o número de endereços disponíveis em uma sub-rede com base no tamanho do bloco CIDR especificado:

Endereços disponíveis em uma sub-rede com base no tamanho do bloco CIDR
Tamanho do bloco CIDR	Endereços disponíveis
/22	1019
/23	507
/24	251
/25	123
/26	59
/27	27
/28	11

Com base nessas duas considerações, as seguintes suposições são feitas para este exemplo:

Os intervalos CIDR do bloco 172.16.0.0/12 dos endereços RFC 1918 são usados para todas as sub-redes.
A camada de apresentação do aplicativo é uma camada fina em uma API REST. Portanto, a escala horizontal afeta a camada do meio mais do que afeta a camada de apresentação.

Determine o tamanho da sub-rede da camada

A próxima etapa é determinar o tamanho da sub-rede de cada camada (em termos de endereços disponíveis). Como cada camada do aplicativo tem uma presença em cada zona, três sub-redes serão necessárias para cada zona.

Considere as informações a seguir ao planejar o tamanho da sub-rede de cada camada:

A camada de banco de dados (o back-end) é a menos propensa a precisar de ajuste de escala dinâmico, portanto, essas sub-redes são as menores. Ou seja, essas sub-redes podem conter o menor número de endereços disponíveis.
- Este exemplo usa um bloco CIDR /27, que permite 27 endereços nessa camada.
A camada intermediária é a que mais provavelmente precisará do dimensionamento dinâmico, portanto, essas sub-redes são as maiores. Ou seja, elas devem conter o maior número de endereços disponíveis.
- Este exemplo usa um bloco CIDR /25, que permite 123 endereços nessa camada.
A camada de front-end está no meio termo, pois não precisa de tantos endereços quanto a camada intermediária e precisa de mais endereços do que a camada de banco de dados.
- Este exemplo usa um bloco CIDR /26, que permite 59 endereços nessa camada.

Combinando as sub-redes e selecionando os prefixos de endereço

Para selecionar um prefixo de endereço aceitável para cada zona, é necessário um tamanho de sub-rede grande o suficiente para acomodar todas as três sub-redes em cada camada e ainda deixar espaço para o dimensionamento horizontal e a expansão futura.

Um prefixo de endereço /24 é o menor prefixo no qual essas três sub-redes podem ser combinadas (27 + 123 + 59). Selecione o próximo maior tamanho de sub-rede, não o menor. A designação do próximo maior tamanho de sub-rede (/23) permite o dimensionamento horizontal além dos limites fornecidos anteriormente, pois permite incluir novas sub-redes em cada camada por meio do mesmo prefixo de endereço.

Depois de determinar o tamanho de sub-rede correto, é possível designar os prefixos de endereço reais, um para cada zona:

Prefixos de endereços atribuídos a zonas
Zona	Prefixo de endereço
Zona 1	`172.16.0.0/23`
Zona 2	`172.16.2.0/23`
Zona 3	`172.16.4.0/23`

Por meio dessa base, também é possível designar as três sub-redes dentro de cada zona:

Sub-redes atribuídas em cada zona
Zona	Camada	CIDR da sub-rede
Zona 1	Meio	`172.16.0.0/25`
Zona 1	Frente	`172.16.1.0/26`
Zona 1	Banco de dados	`172.16.1.128/27`
Zona 2	Meio	`172.16.2.0/25`
Zona 2	Frente	`172.16.3.0/26`
Zona 2	Banco de dados	`172.16.3.128/27`
Zona 3	Meio	`172.16.4.0/25`
Zona 3	Frente	`172.16.5.0/26`
Zona 3	Banco de dados	`172.16.5.128/27`

Considerações para estender uma infraestrutura existente

É possível seguir as etapas anteriores ao planejar um VPC que estende uma infraestrutura existente, seja ela sua infraestrutura local, outro VPC ou até mesmo outra nuvem. Tenha em mente que não se deve reutilizar intervalos de endereços existentes. Ao evitar a reutilização de endereço, é possível maximizar sua capacidade de tirar proveito dos recursos do IBM Cloud VPC.