Em uma postagem anterior do meu blog, vimos que criar um VPC é bastante simples. Precisamos apenas fornecer valores para quatro parâmetros e podemos colocar nosso VPC em funcionamento em minutos:
Região
Bloco CIDR
Ambientes
Grupos de Negócios
Destes quatro parâmetros, o bloco CIDR é geralmente o mais difícil de entender. E este parâmetro é crítico – porque uma vez que seu Mule VPC é criado, você não pode mudar seu bloco CIDR. Veremos, nas linhas a seguir, por que esse parâmetro é tão importante e como calculá-lo corretamente.
Contents
1 O que é o bloco CIDR?
2 Blocos CIDR em seus AnyPoint VPCs
3 Como estimar o número de IPs necessários
3.1 Número de trabalhadores
3.2 Escala horizontal e alta disponibilidade
3.3 Tolerância a falhas (região do VPC)
3.4 Tempo de inatividade zero
3.5 Número de ambientes
3.6 Related posts:
O que é o bloco CIDR?
Para entender o bloco CIDR, devemos primeiro entender o que é um endereço IP (não se preocupe, esta não será uma lição de rede). Um endereço IP é a representação numérica de um local em uma rede. Da mesma forma como seu número de telefone identifica seu telefone celular, seu endereço IP identifica seu dispositivo, seu servidor e sua interface de rede.
Os computadores só entendem números binários, por isso um endereço IP é apenas uma seqüência de zeros e uns. Para ser mais específico, um endereço IP usa uma combinação de 32 zeros e uns de 32 bits. Os humanos, entretanto, precisam de outro formato. É por isso que esse número binário é dividido em quatro blocos ou bytes e cada bloco é representado por um valor decimal. Cada número decimal vai de 0 a 255 (representação decimal de oito 1s). Por causa disso, você sempre vê um endereço IP como uma combinação de quatro números decimais, algo como 192.168.1.1.
CIDR significa notação de roteamento entre domínios sem classes. Esta é a notação que usamos para identificar redes e hosts nas redes. Uma rede é apenas um conjunto de dispositivos, computadores, servidores, em geral um conjunto de hosts interconectados. Um host é qualquer coisa com um endereço IP associado.
Em termos de endereçamento IP, para criar uma rede ou sub-rede, precisamos pegar um segmento de endereços IP consecutivos de todo o espaço de endereçamento IP. E para isso, a notação CIDR nos ajudará a identificar nossa rede e cada host nessa rede.
A notação CIDR consiste em um endereço IP, um caractere de barra (‘/’) e um número decimal de 0 a 32. Usando essa notação, pegamos o endereço IP e o dividimos em dois blocos de bits: os bits mais significativos, os o prefixo de rede representa a rede e o segundo bloco identifica o host nessa rede. O número após o caractere de barra (as máscaras de sub-rede) nos informa quantos bits precisamos para o prefixo de rede.
Por exemplo, vamos ver 192.168.0.0/24:
Endereço IP: 192.168.0.0
Máscara de sub-rede: 255.255.255.0
11000000 10101000 00000000 00000000
11111111 11111111 00000000 00000000
Neste exemplo, usamos 24 bits para a representação da rede e os 8 bits restantes para identificar hosts dentro desta rede. Isso significa que temos 28 = 256 endereços IP possíveis para nossos hosts. Em outras palavras, estamos dimensionando nossa rede para 256 hosts.
Abaixo você pode encontrar uma tabela com os tamanhos dos blocos e seus respectivos números de endereços IP:
Blocos CIDR em seus AnyPoint VPCs
Por que tudo isso é relevante para nosso AnyPoint VPC? Porque quando criamos um VPC estamos atribuindo um tamanho para esse VPC, estamos definindo o número de IPs que podemos usar em nosso VPC.
Quando implantamos um aplicativo Mule em nosso VPC, ele obterá pelo menos um endereço IP do bloco CIDR do VPC. Este bloco CIDR determina o intervalo de endereços IP alocados para seus aplicativos no VPC.
Para um Anypoint VPC, o tamanho desse CIDR precisa ser um número entre 24 (256 Ips) e 16 (65.536 IPs). Ter um bloqueio curto pode fazer com que sua implantação fique sem IPs e não será possível implantar aplicativos no VPC. Dessa perspectiva, definir o tamanho do VPC para o bloco CIDR máximo seria a melhor solução, no entanto, há outra coisa que precisamos considerar.
No momento em que conectarmos este VPC ao nosso Data Center, usando uma VPN ou um peering de VPC, esse bloco CIDR se tornará parte de nossa rede interna e consumirá endereços IP privados de seu espaço de endereçamento interno. Por esse motivo, é importante não superdimensionar seu VPC, pois ele tirará mais IPs do que o necessário de sua rede interna. Para muitas organizações, se considerarmos a quantidade de soluções SaaS que exigem uma conexão privada, torna-se um desafio reservar grandes blocos CIDR para todas elas.
Como estimar o número de IPs necessários
Considerando o acima, como podemos estimar o número de IPs que precisamos para nossa implantação Mule? Comece com o número de aplicativos que implementaremos em nosso VPC. A chave é entender que não existe uma relação de 1 para 1 entre aplicativos e IPs. É provável que um aplicativo consuma mais de um IP.
Estes são os principais conceitos a serem compreendidos para fazer uma estimativa adequada para o bloco CIDR:
Número de trabalhadores
Um aplicativo Mule é implantado para um ou mais trabalhadores. Cada trabalhador obtém seu próprio endereço IP, portanto, um aplicativo implantado para um trabalhador obterá um IP e o mesmo aplicativo implantado para quatro trabalhadores obterá quatro IPs.
Escala horizontal e alta disponibilidade
Você precisa estimar quantos trabalhadores seu aplicativo precisa. Existem basicamente dois motivos para adicionar mais de um trabalhador ao seu aplicativo:
Escalonamento horizontal: alguns aplicativos, devido ao tipo de processamento que o aplicativo faz, requerem mais de um trabalhador para distribuir a carga entre os trabalhadores e obter melhor desempenho.
Alta disponibilidade: se seu aplicativo for crítico, você precisará adicionar mais trabalhadores para que, se um trabalhador falhar, o aplicativo possa continuar atendendo a solicitações com os outros trabalhadores.
Tolerância a falhas (região do VPC)
O Mule VPC é um recurso hospedado no nível da região. Isso significa que os workers de um aplicativo podem ser distribuídos em todas as zonas de disponibilidade da região, de modo que, se uma zona de disponibilidade ficar indisponível, outros workers do mesmo aplicativo em uma AZ diferente possam manter o aplicativo ativo. Com isso em mente, precisamos pensar quão críticos são os aplicativos a serem implantados em um VPC. Fornecer mais do que um trabalhador para um aplicativo nos dará tolerância a falhas no nível do trabalhador, mas se exigimos tolerância a falhas para toda a região, precisamos fornecer um trabalhador por AZ. Dependendo da região em que estamos criando nosso VPC, pode haver três ou quatro AZs. Portanto, se a tolerância a falhas for necessária no nível da região, você precisará descobrir o número de AZs nessa região. Por exemplo, para a região de Frankfurt, temos três AZs, então haveria três trabalhadores para um aplicativo tolerante a falhas na região, e isso são três IPs para um aplicativo.
Tempo de inatividade zero
A implantação com tempo de inatividade zero é um estilo de implantação que permite ao CloudHub implantar novas versões de um aplicativo sem causar nenhuma interrupção aos consumidores do aplicativo. Com esta técnica, podemos implantar uma nova versão do nosso aplicativo ou atualizar o tempo de execução sem interrupção do serviço. Também é útil se precisarmos dimensionar nosso aplicativo, vertical ou horizontalmente. O tempo de inatividade zero alavanca uma implantação lado a lado, para qualquer uma dessas operações, o CloudHub inicia um novo trabalhador com a nova versão do aplicativo e mantém ambos os trabalhadores (o novo e o antigo) até que o antigo seja removido e o novo um permanece.
Nesse processo, o novo trabalhador exigirá um novo IP e, por um período de tempo, teremos dois trabalhadores e, portanto, dois IPs em execução. Portanto, o tempo de inatividade zero afeta o tamanho necessário de nosso bloco CIDR. Precisamos ter IPs livres suficientes no intervalo de IP de nosso VPC para que possamos duplicar o número de IPs atribuídos a aplicativos existentes quando uma atualização em massa acontecer. Portanto, as perguntas a serem respondidas são:
Quantos aplicativos você atualizaria em paralelo?
Você precisa atualizar seus aplicativos em grupos?
Você atualiza seus tempos de execução periodicamente? Quantas versões diferentes do tempo de execução do mule você mantém em sua implantação?
Como a segurança e o patching contínuo afetam seus aplicativos?
Que tipo de tráfego você tem para seus aplicativos? Existe um grupo de aplicativos essenciais em sua implantação que você normalmente dimensiona vertical ou horizontalmente para acomodar picos de tráfego?
Responder a todas essas perguntas daria a você uma melhor compreensão do bloco de IPs que você precisa manter não utilizado em seu bloco CIDR para operações com tempo de inatividade zero. Se você quiser ter certeza de que terá IPs suficientes, planeje o pior cenário, ou seja, duas vezes o número de workers ou IPs em seu VPC.
Número de ambientes
Cada ambiente (e os aplicativos implantados nele) será hospedado em um e apenas um VPC. O mesmo ambiente não pode pertencer a dois VPCs diferentes. Muitas vezes, o mesmo aplicativo terá uma versão do aplicativo para cada ambiente: a versão rodando em produção mais a versão que temos em dev, QA e / ou teste, por exemplo. Por esse motivo, precisamos considerar quantos ambientes hospedaremos no mesmo VPC.
A recomendação é ter pelo menos dois VPCs, um para ambientes de produção e outro para ambientes de não produção. Você precisa prestar atenção nos casos em que pode ter vários ambientes de não produção, pois isso significa multiplicar por dois, três ou mais o número de IPs necessários para o mesmo aplicativo. E mais uma pergunta: você está mantendo uma versão do aplicativo em todos os ambientes para todos os aplicativos?
Com isso, certifique-se de planejar com antecedência, obter o número de aplicativos e o número de trabalhadores por aplicativo. O resto é apenas matemática.