How to choose the CIDR block for your VPC

By -

In one of my previous blog posts, we saw that creating a VPC is quite simple. We just need to provide values to four parameters and we can get our VPC up and running in minutes:

  • Region
  • CIDR Block
  • Environments
  • Business Groups
From these four parameters, the CIDR block is usually the trickiest one to understand. And this parameter is critical — because once your Mule VPC is created, you can’t change your CIDR block. We’ll see, in the following lines, why this parameter is so important and how to properly calculate it.

What is the CIDR block?

To understand the CIDR block, we must first understand what an IP address is (don’t worry, this isn’t going to be a networking lesson). An IP address is the numerical representation of a location in a network. Similarly to how your phone number identifies your cell phone, your IP address identifies your device, your server, and your network interface.

Computers only understand binary numbers, for that reason an IP address is just a sequence of zeros and ones. To be more specific, an IP address uses a combination of 32 zeros and ones, 32 bits. Humans, however, need another format. That's why that binary number is split into four blocks or bytes and each block is represented with a decimal value. Each decimal number goes from 0 to 255 (decimal representation of eight 1s). Because of that, you always see an IP address as a combination of four decimal numbers, something like 192.168.1.1.
image.png CIDR stands for classless inter-domain routing notation. This is the notation that we use to identify networks and hosts in the networks. A network is just a collection of devices, computers, servers, in general a collection of hosts interconnected. A host is anything with an IP address associated.

In terms of IP addressing, to create a network or a subnet, we need to take a segment of consecutive IP addresses from the whole IP addressing space. And for that, the CIDR notation will help us identify our network and each host in that network.

The CIDR notation consists of an IP address, a slash character (‘/’) and a decimal number from 0 to 32. Using this notation we take the IP address and we split it into two blocks of bits: the most significant bits, the network prefix represents the network, and the second block identifies the host in that network. The number after the slash character (the subnet masks) tells us how many bits we need to take for the network prefix.

For example, let’s see 192.168.0.0/24:

IP Address: 192.168.0.0

Subnet Mask: 255.255.255.0

11000000 10101000 00000000 00000000

11111111 11111111 00000000 00000000

In this example, we use 24 bits for the network representation and the remaining 8 bits to identify hosts within this network. This means we’ve got 28 = 256 possible IP addresses for our hosts. In other words, we are sizing our network to 256 hosts.

Below you can find a table with the block sizes and their corresponding number of IP addresses:
image.png

CIDR blocks in your AnyPoint VPCs

Why is all of this relevant for our AnyPoint VPC? Because when we create a VPC we are assigning a size for that VPC, we are defining the number of IPs that we can use in our VPC.

When we deploy a Mule app within our VPC it will get at least one IP address from the CIDR block of the VPC. This CIDR block determines the range of IP addresses allocated for your apps in the VPC.

For an Anypoint VPC, the size of this CIDR needs to be a number between 24 (256 Ips) and 16 (65,536 IPs). Having a short block might cause your deployment to run out of IPs and it won’t be able deploy apps in the VPC. From that perspective, setting your VPC size to the maximum CIDR block would be the best solution, however there´s something else we need to consider.

The moment we connect this VPC to our Data Center, using a VPN or a VPC peering, that CIDR block will become part of our internal network and it will consume private IP addresses from your internal addressing space. For that reason, it's important not to oversize your VPC, as it will take out more IPs than necessary from your internal network. For many organizations, If we consider the amount of SaaS solutions that require a private connection, it becomes a challenge to reserve big CIDR blocks for all of them.

How to estimate the number of IPs required

Considering the above, how do we estimate the number of IPs we need for our Mule deployment? Start from the number of applications we’ll deploy in our VPC. The key is to understand that there's not a 1 to 1 relation between apps and IPs. It's likely that one application will consume more than one IP.

These are the key concepts to understand to do a proper estimation for the CIDR block:

Number of workers

A Mule app is deployed to one or more workers. Every worker gets its own IP address, so an app deployed to one worker will get one IP and the same app deployed to four workers will get four IPs.

Horizontal scaling and high availability

You need to estimate how many workers your app needs. There are mainly two reasons to add more than one worker to your app:
  • Horizontal Scaling: Some apps, due to the type of processing the app does, require more than one worker to distribute the load between the workers and get better performance.
  • High availability: If your app is critical you need to add additional workers so that if one worker fails the app can continue serving requests with the other workers.

Fault tolerance (region of the VPC)

The Mule VPC is a resource hosted at the region level. This means workers of an application can be distributed across all the availability zones in the region, so that if one availability zone becomes unavailable other workers of the same app in a different AZ can keep the application up. With that in mind, we need to think how critical are the apps to deploy in a VPC. Providing more than a worker for an app will give us fault tolerance at the worker level, but if we required fault tolerance for the whole region we need to provide one worker per AZ. Depending on the region we're creating our VPC there might be three or four AZs. So, if fault tolerance is needed at the region level, you need to find out the number of AZs in that region. For example, for the Frankfurt Region, we've got three AZs, then there would be three workers for a fault tolerant app in the region, and that is three IPs for an app.

Zero down-time

Zero downtime deployment is a deployment style that allows CloudHub to deploy new versions of an application without causing any interruption to the consumers of the application. With this technique we can deploy a new version of our app or update the runtime with no service interruption. It is also useful if we need to scale our app, vertically or horizontally. Zero downtime leverages a side-by-side deployment, for any of those operations CloudHub starts up a new worker with the new version of the app and keeps both workers (the new and the old one) until the old one is removed and the new one remains.

In this process, the new worker will require a new IP, and for a period of time we'll have two workers, and therefore two IPs running. So, zero downtime affects the required size of our CIDR block. We need to have enough free IPs in the IP range of our VPC so that we could duplicate the number of IPs assigned to existing apps when a bulk update happens. So, questions to answer are:
  • How many apps would you be updating in parallel?
  • Do you need to update your apps in groups?
  • Do you update your runtimes periodically? How many different versions of the mule runtime do you keep in your deployment?
  • How does security and continuous patching affect your apps?
  • What type of traffic do you have for your apps? Is there a group of critical apps in your deployment that you typically scale vertically or horizontally to accommodate peaks of traffic?
Answering all these questions would give you a better understanding of the block of IPs you need to maintain unused in your CIDR block for zero downtime operations. If you want to be certain that you'll have enough IPs, just plan for the worst case scenario, that is, two times the number of workers or IPs in your VPC.

Number of environments

Each environment (and the apps deployed on it) will be hosted in one and only one VPC. The same environment cannot belong to two different VPCs. Oftentimes, the same application will have a version of the app for every environment: the version running in production plus the version we have in dev, QA and/or test, for instance. For that reason, we need to consider how many environments we will host in the same VPC.

The recommendation is to have at least two VPCs, one for production environments and another for non-production environments. You need to pay attention in those cases in which you can have multiple non production environments because that means multiplying by two, three, or more the number of IPs required for the same app. And something else to ask: are you maintaining a version of the app in all environments for all apps?

With that, be sure to plan ahead, get the number of apps and the number of workers per app. The rest is just maths.

Popular posts from this blog

Benefici di Mule 4 - Parte 2

By -
Image
Come evidenziato nel primo post di questa serie , Mule 4 è un runtime con architettura diversa rispetto a quella della versione precedente Mule 3. I nuovi disegno ed architettura di questa versione portano dei miglioramenti sostanziali e nuove funzionalità. Nel post di oggi vedremo quali sono queste novità riguardo lo streaming e classloader isolation. Streaming Che cosa è lo streaming? In informatica, lo streaming è un meccanismo di trasmissione di dati che permette di fruire del contenuto desiderato senza la necessità di aspettare che questo ultimo sia completamente ricevuto. Nel contesto del runtime di Mule, lo streaming consiste  nella capacità di un event processor di incominciare a girare senza aspettare ad aver ricevuto tutti i dati dell processor precedente. Questo, come potete immaginare è incredibilmente utile quando si lavora con grandi quantità di dati, arrays o collections, come nel caso di un insieme di records che provengono dal database, da un file, oppure da uno stre
Read more

MuleSoft Metrics Accelerator

By -
Image
Metrics Accelerator es una herramienta para automatizar la extracción, agregación y la visualizacion de metricas, o mejor dicho, la carga de métricas en un sistema de visualización. Es una herramienta creada por nuestro equipo de Servicios Profesionales de MuleSoft, a partir del trabajo que han hecho para varios de nuestros clientes. Lo han estandarizado y lo han puesto a disposición de la comunidad como proyecto Open Source en GitHub. Por tanto, como proyecto open source se proporciona el código fuente y se deja abierto para que cualquiera pueda colaborar a evolucionarlo. Aquí tenéis el enlace al  proyecto en GitHub de Metrics Accelerator. En esta serie de posts vamos a ver en detalle la herramienta: desde cómo instalarlo hasta cómo crear dashboards en un sistema de visualización, viendo los detalles de funcionamiento y configuración. Aquí tenéis el detalle de los artículos dedicados a Metrics Accelerator: Metrics Accelerator (I) - Qué es y Cómo Instalarlo Metrics Accelerator (II) - T
Read more

The Mule Migration Assistant

By -
Image
La versione 4 del runtime di Mule è ormai da due anni con noi. Questo 2021 abbiamo due date importanti: una a Marzo, a partire dal 20 di Marzo non sarà più possibile pubblicare nuove applicazioni in Mule 3.9, e questa versione passerà a Extended Support fino il 2024. E la seconda data è a Novembre, a partire della quale finirà lo extended support alla versione 3.8 e di conseguenza tutte le applicazioni in questa versione non funzioneranno più. Potete trovare più informazione su questo link.   Version Release Date End of Standard Support End of Extended Support 4.3 April 30, 2020 April 30, 2022 April 30, 2024 4.2 May 2, 2019 May 2, 2021 May 2, 2023 4.1 March 20, 2018 November 2, 2020 November 2, 2022 3.9 long term supported October 9, 2017 March 20, 2021 March 20, 2024 3.8 long term supported May 16, 2016 November 16, 2018 November 16, 2021 3.7 July 9, 2015 November 16, 2017 January 25, 2020 3.6 January 15, 2015 January 15, 2017 N/A 3.5 long term supported May 20, 2014 July 15, 2016 *
Read more

Cómo configurar Postman para usar las Platform APIs de AnyPoint

By -
Image
Postman se ha convertido en los últimos años en la herramienta standard para cualquier desarrollador de APIs. Nos proporciona una interfaz intuitiva y sencilla para interactuar y probar APIs en general. Y, en particular, para nuestro trabajo con Mule hay dos escenarios donde Postman nos es muy útil. El primero, obviamente, como herramienta de testing. Una vez construidas nuestras Mule APIs podemos usar Postman para probar las distintas operaciones de nuestras APIs: GET, POST, PUT..., podemos construir nuestro JSON para las request e incluso podemos hacer nuestras pruebas con distintos métodos de autenticación en las APIs, por poner varios ejemplos. El otro caso de uso, para el que Postman nos es muy util como desarrolladores Mule, es para interactuar con las Platform APIs de Anypoint. Para los que no las conozcáis, las AnyPoint Platform APIs son el conjunto de APIs que MuleSoft pone a disposición para interactuar con todas las funcionalidades de AnyPoint Platform de forma programá
Read more

Benefici di Mule 4 - Parte I

By -
Image
La versione 4 del runtime di Mule è ormai da due anni con noi. Questo anno, come abbiamo visto in un altro post sul Mule Migration Assistant , è l'anno chiave per migrare da Mule 3. Mule 4 è la migliore versione del runtime al momento con tanti miglioramenti rispetto alla versione precedente. Per quelli che ancora non sono convinti, in questa serie di posts vedremo le principali novità di Mule 4. In questo primo post vedremo i cambiamenti fatti sulla struttura dei eventi Mule, la gestione dei threads e le caratteristiche non-blocking e self-tuning di Mule 4. Struttura dell’Evento Mule La prima cosa che si è semplificata nella versione 4 è la struttura del messaggio Mule, ovvero l’evento Mule. Un’evento Mule è l’unita di informazione, sulla quale lavora il runtime. Ogni messaggio inviato ad una applicazione Mule, sia un messaggio di tipo HTTP, JMS, MQ che in qualsiasi altro protocollo o formato è convertito a questo formato di evento, e poi ogni trasformazione o ulteriore elaborazi
Read more

MuleSoft Metrics Accelerator (I) - Qué es y Cómo Instalarlo

By -
Image
Metrics Accelerator es una herramienta para automatizar la extracción, agregación y la visualizacion de metricas, o mejor dicho, la carga de métricas en un sistema de visualización. Es una herramienta creada por nuestro equipo de Servicios Profesionales de MuleSoft, a partir del trabajo que han hecho para varios de nuestros clientes. Lo han estandarizado y lo han puesto a disposición de la comunidad como proyecto Open Source en GitHub. Por tanto, como proyecto open source se proporciona el código fuente y se deja abierto para que cualquiera pueda colaborar a evolucionarlo. Aquí tenéis el enlace al proyecto en GitHub de Metrics Accelerator. En esta serie de posts vamos a ver en detalle la herramienta: desde cómo instalarlo hasta cómo crear dashboards en un sistema de visualización, viendo los detalles de funcionamiento y configuración. En este primer post veremos cómo instalarlo y empezar a utilizarlo. Y, en los próximos veremos: Metrics Accelerator (II) - Tipos de Métricas Metrics Acce
Read more

MuleSoft Metrics Accelerator (IV) - Visualización en Splunk

By -
Image
En este nuevo post dedicado a Metrics Accelerator vamos a ver un ejemplo de cómo enviar nuestras métricas a un sistema de visualización, en concreto a Splunk. Este post pertenece a la serie de posts dedicada a Metrics Accelerator, si todavia no sabes qué es o cómo funciona te aconsejo empezar con los posts anteriores: Metrics Accelerator (I) - Qué es y Cómo Instalarlo Metrics Accelerator (II) - Tipos de Métricas Metrics Accelerator (III) - Modos de Ejecución Metrics Accelerator (IV) - Visualización en Splunk Metrics Accelerator permite el envio programado y automático de las métricas extraidas por la aplicación a un sistema externo de visualización. Como ejemplo, veamos como configurar Metrics Accelerator para enviar estos datos a Splunk en los siguientes sencillos pasos: 1. Configuración en Splunk Indices en Splunk. Desde Settings/Data seleccionamos la opcion Indexes y crearemos dos índices: metrics y platform _benefits , del tipo Events. Configurar o crear un nuevo HTTP Event Co
Read more

MuleSoft Metrics Accelerator (III) - Modos de Ejecución

By -
Image
En este tercer post de la serie dedicada a Metrics Accelerator  entraremos en sus detalles de configuración y veremos los ajustes necesarios para hacerlo funcionar en modo API o en modo Poller. Si todavía no conoces Metrics Accelerator o para qué sirve, te aconsejo que empieces por los primeros post y vuelvas a éste. Aquí abajo te dejo la lista de posts dedicada a Metrics Accelerator: Metrics Accelerator (I) - Qué es y Cómo Instalarlo Metrics Accelerator (II) - Tipos de Métricas Metrics Accelerator (III) - Modos de Ejecución Metrics Accelerator (IV) - Visualización en Splunk La aplicación de Metrics Accelerator viene preparada para trabajar en dos modos: API mode y Poller mode. Fundamentalmente para cubrir los dos grandes casos de uso que veremos a continuación: API Mode Como hemos visto durante el setup inicial en el primer post de esta serie , la aplicación nos proporciona una serie de endpoints que podemos consultar y obtener datos en cualquier momento. No hace falta configurar na
Read more

How many VPCs do I need?

By -
Image
In my previous blog post , we explained the different scenarios required to get a VPC in place. But there’s yet another question we need to answer before creating our first VPC. Is it enough with one VPC? How many VPCs do I really need? In this blog post, we’ll review some of the considerations to decide how many VPCs should be included into our network architecture. Backend location If we are going to be connecting our VPC(s) to our data center to provide your Mule apps with access to your back-end systems, the first question to ask is where the backend is. The Mule VPC will be created in an AWS Region, so create this VPC in the closest region to our backend to minimize the latency in the communications. However, many organizations don’t have a unique location for their data center. Sometimes data centers are geographically distributed in different on-prem locations or in different regions of a cloud provider. If that’s the case, you have two options: Create one VPC and connection
Read more