IBM Cloud Docs
Conception d'un plan d'adressage pour un VPC

Conception d'un plan d'adressage pour un VPC

La première étape de la conception de votre IBM Cloud® Virtual Private Cloud est la conception de votre plan d'adressage.

Un plan d'adressage correctement conçu a deux objectifs :

  • Il répond aux exigences de communication des instances du VPC.
  • Il maintient la flexibilité pour la croissance future.

Ce document donne un exemple de conception d'un plan d'adressage pour une application Web à trois niveaux, dans laquelle chaque niveau est pris en charge par plusieurs zones.

Bien que chaque IBM Cloud VPC soit déployé dans une région spécifique, le VPC peut couvrir toutes les zones de cette région. IBM Cloud VPC définit un préfixe d'adresse par défaut pour chaque zone. Les préfixes d'adresse permettent la communication entre les instances de VPC dans différentes zones.

Les étapes de conception requises sont les mêmes, que l'application s'exécute entièrement dans le cloud ou partiellement.

Lorsque vous créez des instances VPC que vous avez l'intention d'interconnecter en utilisant IBM Cloud Transit Gateway, évitez de sélectionner des préfixes d'adresse par défaut. Créez vos instances VPC avec des préfixes sans chevauchement pour une connectivité réussie.

Lorsque vous créez des instances VPC que vous souhaitez interconnecter avec votre infrastructure IBM Cloud classic en utilisant IBM Cloud Transit Gateway, n'utilisez pas d'adresses IP dans vos instances dans les blocs 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15 et 10.254.0.0/16. Évitez également les adresses IP des sous-réseaux de votre infrastructure classique.

Pour plus d'informations sur la conception de vos instances VPC en vue de leur utilisation avec IBM Cloud Transit Gateway, voir Planning for IBM Cloud Transit Gateway.

Considérations et hypothèses de conception

Lorsque vous concevez le plan d'adressage pour une application, la principale considération est de conserver les blocs CIDR utilisés pour créer des sous-réseaux dans une zone unique aussi contiguë que possible. De la sorte, vous pouvez les regrouper dans un même préfixe d'adresse, ce qui laisse de la place pour une croissance future.

Une autre considération est le nombre d'adresses disponibles dont un sous-réseau peut avoir besoin pour une mise à l'échelle horizontale. Le tableau 1 répertorie le nombre d'adresses disponibles dans un sous-réseau, en fonction de la taille de bloc CIDR spécifiée :

Adresses disponibles dans un sous-réseau en fonction de la taille du bloc CIDR
Taille de bloc CIDR Adresses disponibles
/22 1019
/23 507
/24 251
/25 123
/26 59
/27 27
/28 11

Sur la base de ces deux considérations, les hypothèses suivantes sont faites pour cet exemple:

  • Les plages CIDR du bloc 172.16.0.0/12 des adresses RFC 1918 sont utilisées pour tous les sous-réseaux.
  • La couche de présentation de l'application est une couche fine sur une API REST. Par conséquent, la mise à l'échelle horizontale affecte davantage le niveau intermédiaire que le niveau de présentation.

Détermination de la taille du sous-réseau de chaque niveau

L'étape suivante consiste à déterminer la taille du sous-réseau de chaque niveau (en termes d'adresses disponibles). Chaque niveau de l'application étant présent dans chaque zone, chaque zone nécessite trois sous-réseaux.

Tenez compte des informations suivantes lorsque vous planifiez la taille de sous-réseau de chaque niveau:

  • Le niveau de base de données (back-end) étant le moins susceptible d'avoir besoin d'une mise à l'échelle dynamique, ces sous-réseaux sont les plus petits. En d'autres termes, ces sous-réseaux peuvent contenir le nombre minimal d'adresses disponibles.
    • Cet exemple utilise un bloc CIDR /27 qui permet d'utiliser 27 adresses dans ce niveau.
  • Le niveau intermédiaire est le plus susceptible de nécessiter une mise à l'échelle dynamique ; ces sous-réseaux sont donc les plus grands. C'est-à-dire qu'ils doivent contenir le plus grand nombre d'adresses disponibles.
    • Cet exemple utilise un bloc CIDR /25 qui permet d'utiliser 123 adresses dans ce niveau.
  • Le niveau de front-end s'adapte au niveau intermédiaire ; il n'a pas besoin d'autant d'adresses que le niveau intermédiaire, mais il en nécessite davantage que le niveau de base de données.
    • Cet exemple utilise un bloc CIDR /26 qui autorise 59 adresses dans ce niveau.

Combinaison des sous-réseaux et sélection des préfixes d'adresse

Pour sélectionner un préfixe d'adresse acceptable pour chaque zone, vous avez besoin d'une taille de sous-réseau suffisamment grande pour accueillir les trois sous-réseaux de chaque niveau, tout en laissant une marge pour la mise à l'échelle horizontale et une extension future.

Le préfixe d'adresse /24 est le plus petit préfixe dans lequel ces trois sous-réseaux peuvent être combinés (27 + 123 + 59). Sélectionnez la taille de sous-réseau suivante, et non la plus petite. L'affectation de la taille de sous-réseau supérieure suivante (/23) permet une mise à l'échelle horizontale au-delà des limites indiquées précédemment, car elle permet d'ajouter de nouveaux sous-réseaux à chaque couche, à partir du même préfixe d'adresse.

Une fois que vous avez déterminé la taille de sous-réseau appropriée, vous pouvez affecter les préfixes d'adresse réels (un par chaque) :

Préfixes d'adresses attribués aux zones
Zone Préfixe d'adresse
Zone 1 172.16.0.0/23
Zone 2 172.16.2.0/23
Zone 3 172.16.4.0/23

A partir de cette base, vous pouvez affecter les trois sous-réseaux de chaque zone :

Sous-réseaux attribués dans chaque zone
Zone Niveau CIDR de sous-réseau
Zone 1 Milieu 172.16.0.0/25
Zone 1 Avant 172.16.1.0/26
Zone 1 Base de données 172.16.1.128/27
Zone 2 Milieu 172.16.2.0/25
Zone 2 Avant 172.16.3.0/26
Zone 2 Base de données 172.16.3.128/27
Zone 3 Milieu 172.16.4.0/25
Zone 3 Avant 172.16.5.0/26
Zone 3 Base de données 172.16.5.128/27

Considérations pour l'extension d'une infrastructure existante

Lorsque vous planifiez un VPC qui étend une infrastructure existante, vous pouvez suivre les étapes précédentes, qu'il s'agisse d'une infrastructure sur site, d'un autre VPC ou même d'un autre cloud. Gardez à l'esprit que vous ne devez pas réutiliser les plages d'adresses existantes. En évitant la réutilisation des adresses, vous pouvez optimiser votre capacité à tirer parti des fonctionnalités de IBM Cloud VPC.