Nesse post, vamos tratar de um assunto que costuma ser pouco falado, mas que acaba ajudando bastante a manter a organização da sua infraestrutura de rede. Principalmente se você esta utilizando IaC e modelos de terraformação.
Quando falamos de rede de computadores, não podemos pensar em colocar todos os nossos equipamentos sobre o mesmo grupo de IPs (mesma rede).
Devemos dividir nossa estruturas em redes diferentes para garantir o isolamento dos recursos de acordo com as suas finalidades. Principalmente se o conteúdo que esta na rede utiliza pacotes de camada 2, como multicast.
Para isso, uma boa ideia, é você dividir suas redes de uma forma “matemática” permitindo assim um controle da sua expansão. Abaixo, temos uma tabela que vai nos permitir servir de exemplo.
| # | Inicio | Fim | Exemplos | Utilização / Função | |||
|---|---|---|---|---|---|---|---|
| 1 | 0 | 14 | 172.0.0.0/16 | 172.1.0.0/16 | … | 172.14.0.0/16 | Gerenciamento |
| 2 | 15 | 29 | 172.15.0.0/16 | 172.16.0.0/16 | … | 172.29.0.0/16 | Shared |
| 3 | 30 | 44 | 172.30.0.0/16 | 172.31.0.0/16 | … | 172.44.0.0/16 | Dev |
| 4 | 45 | 59 | 172.45.0.0/16 | 172.46.0.0/16 | … | 172.59.0.0/16 | Hml |
| 5 | 60 | 74 | 172.60.0.0/16 | 172.61.0.0/16 | … | 172.74.0.0/16 | QA |
| 6 | 75 | 89 | 172.75.0.0/16 | 172.76.0.0/16 | … | 172.89.0.0/16 | Prd |
| 7 | 90 | 104 | 172.90.0.0/16 | 172.91.0.0/16 | … | 172.104.0.0/16 | |
| 8 | 105 | 119 | 172.105.0.0/16 | 172.106.0.0/16 | … | 172.119.0.0/16 | |
| 9 | 120 | 134 | 172.120.0.0/16 | 172.121.0.0/16 | … | 172.134.0.0/16 | |
| 10 | 135 | 149 | 172.135.0.0/16 | 172.136.0.0/16 | … | 172.149.0.0/16 | |
| 11 | 150 | 164 | 172.150.0.0/16 | 172.151.0.0/16 | … | 172.164.0.0/16 | |
| 12 | 165 | 179 | 172.165.0.0/16 | 172.166.0.0/16 | … | 172.179.0.0/16 | |
| 13 | 180 | 194 | 172.180.0.0/16 | 172.181.0.0/16 | … | 172.194.0.0/16 | |
| 14 | 195 | 209 | 172.195.0.0/16 | 172.196.0.0/16 | … | 172.209.0.0/16 | |
| 15 | 210 | 224 | 172.210.0.0/16 | 172.211.0.0/16 | … | 172.224.0.0/16 | |
| 16 | 225 | 239 | 172.225.0.0/16 | 172.226.0.0/16 | … | 172.239.0.0/16 | |
| 17 | 240 | 254 | 172.240.0.0/16 | 172.241.0.0/16 | … | 172.254.0.0/16 | |
Matemática.
Dividimos 255 por 17, que nos dá 15. Ou seja. Temos 17 grupos com 15 conjuntos.
Explicando a ideia.
Pegando a linha 3 da tabela, temos as redes 172.30.0.0/16 a 172.44.0.0/16.
Com isso, temos um range de 14 grupos de redes:
- 172.30.0.0/16
- 172.31.0.0/16
- 172.32.0.0/16
- 172.33.0.0/16
- 172.34.0.0/16
- 172.35.0.0/16
- 172.36.0.0/16
- 172.37.0.0/16
- 172.38.0.0/16
- 172.39.0.0/16
- 172.40.0.0/16
- 172.41.0.0/16
- 172.42.0.0/16
- 172.43.0.0/16
- 172.44.0.0/16
Dado essas redes, podemos escolher um conjunto desses endereços para montar nosso ambiente. Como exemplo:
Mas qual é a grande vantagem desse modelo?
Que se você precisar criar uma nova estrutura seguindo um conjunto já existente, você não tem conflito de endereços.
Explicando melhor. Promover essa infraestrutura de desenvolvimento para produção, seria recriar seu ambiente escolhendo outro conjunto do endereços, como o conjunto da linha 6.
Trocando:
de 172.30.0.0/16 para 172.75.0.0/16
de 172.33.0.0/16 para 172.78.0.0/16
de 172.35.0.0/16 para 172.81.0.0/16
E assim, sucessivamente.
Precisa ter 2 produção no ar? Basta pegar outro range.
Precisa de um novo QA por um período de tempo? Basta pega outro range.
Esse modelo, permite ter 15 “ambientes” simultâneos, pois os 2 primeiros ranges são “fixos”. Mas acredito ser muito difícil de precisar de mais que isso.
Já tive a necessidade de ter 3 QA e 2 HML em funcionamento juntos. Mas nunca cheguei a usar mais que 10 grupos em paralelo.
O modelo estar em /16 é somente por ser mais próximo da arquitetura atual que estou montando. Nada impede de você replicar em /24 se não estiver precisando de tantos hosts dentro da sua rede.