Diseño de un plan de direcciones para una VPC
El primer paso en el diseño de su IBM Cloud® Virtual Private Cloud es el diseño del plan de direcciones.
Un plan de direcciones diseñado correctamente tiene dos objetivos:
- Se ajusta a los requisitos de comunicación de las instancias de VPC.
- Conserva la flexibilidad para el futuro crecimiento.
Este documento proporciona un ejemplo de diseño del plan de direcciones para una aplicación web de tres niveles, en la que cada nivel está soportado por varias zonas.
Aunque cada IBM Cloud VPC se despliega en una región concreta, el VPC puede abarcar todas las zonas de dicha región. IBM Cloud VPC define un prefijo de dirección predeterminado para cada zona. Los prefijos de dirección permiten la comunicación entre las instancias de VPC en zonas distintas.
Se utilizan los mismos pasos de diseño, independientemente de si la aplicación está contenida completamente en la nube, o si partes de la aplicación se ejecutan en otra ubicación.
Cuando cree instancias de VPC que pretenda interconectar mediante IBM Cloud Transit Gateway, evite seleccionar prefijos de dirección predeterminados. Cree las instancias de VPC con prefijos no solapados para una conectividad correcta.
Cuando cree instancias de VPC que también pretenda interconectar con su infraestructura clásica de IBM Cloud mediante IBM Cloud Transit Gateway, no utilice direcciones IP
en sus instancias en los bloques 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15 y 10.254.0.0/16. Además, evite las direcciones IP de las subredes de su infraestructura clásica.
Para obtener más información sobre el diseño de sus instancias VPC para su uso con IBM Cloud Transit Gateway, consulte Planificar para IBM Cloud Transit Gateway.
Consideraciones y supuestos de diseño
Al diseñar el plan de direccionamiento para una aplicación, la consideración principal es mantener los bloques CIDR utilizados para crear subredes dentro de una única zona lo más contiguos posible. Así, puede resumirlas en un solo prefijo de dirección, lo que permite el crecimiento futuro.
Otra consideración es el número de direcciones disponibles que puede necesitar una subred para el escalado horizontal. En la tabla 1 se lista el número de direcciones disponibles en una subred, según el tamaño de bloque CIDR especificado:
| Tamaño de bloque CIDR | Direcciones disponibles |
|---|---|
| /22 | 1019 |
| /23 | 507 |
| /24 | 251 |
| /25 | 123 |
| /26 | 59 |
| /27 | 27 |
| /28 | 11 |
Basándose en estas dos consideraciones, se realizan las siguientes suposiciones para este ejemplo:
- Se utilizan rangos de CIDR del bloque
172.16.0.0/12de direcciones de RFC 1918 para todas las subredes. - La capa de presentación de la aplicación es una capa fina sobre una API REST. Por lo tanto, el escalado horizontal afecta a la capa media más que a la capa de presentación.
Determine el tamaño de subred de cada nivel
El paso siguiente consiste en determinar el tamaño de subred de cada nivel (en términos de direcciones disponibles). Ya que cada nivel de la aplicación tiene presencia en cada zona, cada zona necesita tres subredes.
Tenga en cuenta la siguiente información cuando planifique el tamaño de subred de cada nivel:
- El nivel de la base de datos (el programa de fondo) es el que con menos probabilidad necesitará escalado dinámico, por lo que estas subredes son las más pequeñas. Es decir, estas subredes pueden contener el menor número de direcciones disponibles.
- Este ejemplo utiliza un bloque CIDR de
/27, que permite 27 direcciones en este nivel.
- Este ejemplo utiliza un bloque CIDR de
- El nivel medio es el que más probablemente necesita el escalado dinámico, por lo que estas subredes son las más grandes. Es decir, deben contener el mayor número de direcciones disponibles.
- Este ejemplo utiliza un bloque CIDR de
/25, que permite 123 direcciones en este nivel.
- Este ejemplo utiliza un bloque CIDR de
- El nivel frontal queda entremedio; no necesita tantas direcciones como el nivel medio, pero necesita más que el nivel de base de datos.
- Este ejemplo utiliza un bloque CIDR de
/26, que permite 59 direcciones en este nivel.
- Este ejemplo utiliza un bloque CIDR de
Combinación de las subredes y selección de los prefijos de dirección
Para seleccionar un prefijo de dirección aceptable para cada zona, necesita un tamaño de subred que sea lo suficientemente grande como para acomodar las tres subredes de cada nivel, y aún así dejar espacio para el escalado horizontal y una futura expansión.
Un prefijo de dirección /24 es el prefijo más pequeño en el que se pueden combinar estas tres subredes (27 + 123 + 59). Seleccione el siguiente tamaño de subred más grande, no el más pequeño. Asignar el siguiente tamaño de subred
más grande (/23) permite el escalado horizontal más allá de los límites que se han dado anteriormente, porque permite añadir nuevas subredes a cada capa, desde dentro del mismo prefijo de dirección.
Después de determinar el tamaño de subred correcto, puede asignar los prefijos de dirección reales, uno para cada zona:
| Zona | Prefijo de dirección |
|---|---|
| Zona 1 | 172.16.0.0/23 |
| Zona 2 | 172.16.2.0/23 |
| Zona 3 | 172.16.4.0/23 |
Y, a partir de esta base, se pueden asignar las tres subredes dentro de cada zona:
| Zona | Nivel | CIDR de subred |
|---|---|---|
| Zona 1 | Centro | 172.16.0.0/25 |
| Zona 1 | Frontal | 172.16.1.0/26 |
| Zona 1 | Base de datos | 172.16.1.128/27 |
| Zona 2 | Centro | 172.16.2.0/25 |
| Zona 2 | Frontal | 172.16.3.0/26 |
| Zona 2 | Base de datos | 172.16.3.128/27 |
| Zona 3 | Centro | 172.16.4.0/25 |
| Zona 3 | Frontal | 172.16.5.0/26 |
| Zona 3 | Base de datos | 172.16.5.128/27 |
Consideraciones para ampliar una infraestructura existente
Al planificar una VPC que amplíe una infraestructura existente, puede seguir los pasos anteriores, tanto si la infraestructura es su infraestructura local, o si es otra VPC o incluso otra nube. Recuerde que no debe reutilizar los rangos de direcciones existentes. Evitando la reutilización de direcciones, puede maximizar su capacidad para beneficiarse de las características de IBM Cloud VPC.