Lors du déploiement de vos services dans un cloud privé virtuel (VPC), planifiez votre réseau en fonction de vos besoins actuels et de vos projections de croissance. Cette démarche garantit que votre réseau répond aux exigences immédiates tout en soutenant le développement de votre activité.
Pour planifier votre réseau, prenez en compte l'isolation sécurisée, la reprise après sinistre et les coûts d'exploitation et de maintenance (O&M). Une planification prospective assure la stabilité de l'activité et l'évolutivité du réseau, tandis qu'une conception manquant de vision peut entraver l'expansion future et introduire des risques imprévus. La reconstruction d'un réseau existant est coûteuse et perturbatrice. Par conséquent, une planification réseau complète et multidimensionnelle est cruciale.
Suivez les étapes ci-dessous pour planifier votre VPC :
Planification des régions et des zones
Au sein d'une région, toutes les zones communiquent via le réseau interne. Chaque zone est isolée des pannes survenant dans les autres zones. Si une zone tombe en panne, les autres continuent de fonctionner normalement. Les instances déployées dans la même zone bénéficient d'une latence réseau plus faible, ce qui accélère l'accès utilisateur.
|
Critère |
Description |
|
Latence |
Le déploiement des ressources à proximité de vos utilisateurs finaux réduit la latence réseau et améliore la vitesse d'accès. |
|
Disponibilité des services |
La disponibilité des services Alibaba Cloud varie selon les régions et les zones. Assurez-vous que les services cloud requis sont disponibles dans les régions et zones sélectionnées. |
|
Coût |
Le prix d'un service cloud peut varier selon la région. Nous vous recommandons de sélectionner une région adaptée à votre budget. |
|
Haute disponibilité et reprise après sinistre |
Pour les services nécessitant de fortes capacités de reprise après sinistre, déployez-les sur plusieurs zones au sein de la même région. Vous pouvez également déployer vos services sur plusieurs régions pour assurer une reprise après sinistre inter-régions. |
|
Conformité |
Sélectionnez une région conforme aux politiques de localisation des données et de dépôt opérationnel de votre pays ou région. |
Un VPC ne peut pas s'étendre sur plusieurs régions. Pour déployer vos services sur plusieurs régions, créez un VPC dans chaque région et connectez-les à l'aide de connexions d'appairage VPC ou de Cloud Enterprise Network (CEN). Un vSwitch est une ressource zonale. Tenez compte des points suivants :
Si vous utilisez plusieurs zones en raison de la disponibilité des services cloud, réservez suffisamment de blocs CIDR et prenez en compte l'augmentation potentielle de la latence causée par le trafic inter-zones.
Certaines régions ne proposent qu'une seule zone, comme China (Nanjing - Local Region, Closing Down). Si vous avez besoin d'une reprise après sinistre intra-région, évaluez soigneusement l'opportunité de sélectionner une telle région.
Planification des comptes et des VPC
Après avoir planifié les régions et les zones, vous pouvez commencer à créer des VPC. Prenez en compte l'échelle de votre activité et l'isolation de sécurité afin d'optimiser l'utilisation des ressources et de réduire les coûts.
Planification de vos comptes
Si votre activité est de petite taille et que vous pouvez gérer toutes les ressources avec un seul compte ou un compte principal avec des utilisateurs RAM, vous pouvez ignorer cette section.
Lorsque l'échelle de votre activité augmente, vous devrez peut-être déléguer les autorisations et appliquer une isolation de sécurité entre les environnements. Dans ce cas, concevez une architecture multi-comptes unifiée.
|
Critère |
Description |
|
Isolation des autorisations |
Créez des comptes distincts pour différentes unités commerciales afin d'isoler les ressources, les coûts et les autorisations pour une gestion simplifiée. Pour les grands projets ou applications ayant des exigences spécifiques, utilisez des comptes séparés pour un meilleur contrôle. |
|
Isolation des systèmes |
Pour les systèmes nécessitant une isolation stricte, tels que les environnements de production et de test, utilisez des comptes dédiés afin de réduire le risque d'interférence. |
|
Conformité en matière de sécurité |
Pour renforcer la conformité en matière de sécurité, conservez les données sensibles et les charges de travail dans des comptes isolés et distincts. |
|
Gestion des coûts |
Utilisez plusieurs comptes pour isoler les ressources. Cela facilite le suivi des coûts et la gestion de la facturation. |
|
Journaux et O&M |
Utilisez un compte indépendant pour stocker les données de journal de tous les comptes à des fins d'audit de sécurité. |
La complexité du réseau augmente avec le nombre de VPC et de comptes. Utilisez la fonctionnalité Shared VPC pour réduire la complexité tout en maintenant la sécurité et la stabilité du réseau.
Planification de votre VPC
Un VPC fournit un environnement réseau sécurisé et flexible. Différents VPC sont complètement isolés les uns des autres, tandis que les ressources au sein du même VPC peuvent communiquer via le réseau privé. Planifiez le nombre de VPC adapté à vos besoins.
Nombre de VPC | Cas d'utilisation |
Un seul |
 |
Plusieurs |
Planifiez plusieurs VPC dans les cas d'utilisation suivants :
|
Par défaut, vous pouvez créer au maximum 10 VPC par région. Pour demander une augmentation de quota, accédez à la page Quota Management ou à la page Quota Center.
Planification de vos vSwitch
Un vSwitch est une ressource zonale. Toutes les ressources cloud d'un VPC sont déployées au sein de vSwitch. La création de vSwitch vous aide à planifier correctement les adresses IP. Tous les vSwitch d'un VPC peuvent communiquer entre eux par défaut.
|
Critère |
Description |
|
Latence |
La latence entre les zones d'une même région est faible. Toutefois, des appels système complexes et des appels inter-zones peuvent augmenter la latence. |
|
Haute disponibilité et reprise après sinistre |
Lors de l'utilisation d'un VPC, créez au moins deux vSwitch et déployez-les sur plusieurs zones pour la reprise après sinistre. Configurez et gérez les règles de sécurité de manière centralisée, ce qui améliore considérablement la haute disponibilité et la reprise après sinistre. |
|
Échelle et division de l'activité |
Créez des vSwitch par modules métier. Par exemple, pour une architecture d'application web standard, créez plusieurs vSwitch pour héberger les couches web, logique et données. |
Planifiez vos vSwitch en suivant les principes ci-dessous :
-
Créez au moins deux vSwitch et déployez-les sur plusieurs zones pour le basculement. Lorsqu'un vSwitch est hors service, l'autre prend le relais et assure la reprise après sinistre.
Notez que la latence réseau peut augmenter en raison de la topologie réseau complexe et des appels inter-zones. Nous vous recommandons d'améliorer votre architecture pour équilibrer à la fois la haute disponibilité et la faible latence.
-
Le nombre de vSwitch dépend de l'échelle et de l'architecture de votre système. En général, les vSwitch sont créés par modules métier. Par exemple, déployez les services exposés à Internet dans un vSwitch public, tandis que les autres services sont regroupés dans différents vSwitch selon leur type. Cela permet de simplifier la configuration et de gérer les règles de sécurité de manière centralisée.
Par défaut, vous pouvez créer au maximum 150 vSwitch par VPC. Pour demander une augmentation de quota, accédez à la page Quota Management ou à la page Quota Center.
Planification des blocs CIDR
Lors de la création d'un VPC et d'un vSwitch, vous devez spécifier les blocs CIDR du VPC et du vSwitch. La taille du bloc CIDR détermine le nombre de ressources pouvant être déployées. Une planification appropriée des blocs CIDR évite les conflits d'adresses et garantit l'évolutivité, tandis qu'une planification inadéquate peut entraîner des coûts de reconstruction élevés.
Une fois que vous avez spécifié un bloc CIDR de vSwitch, vous ne pouvez plus le modifier.
Si l'espace d'adressage est insuffisant en raison d'une mauvaise planification, ajoutez des blocs CIDR secondaires pour l'étendre. Vous ne pouvez pas modifier les blocs CIDR secondaires.
Tenez compte des éléments suivants lors de la planification des blocs CIDR :
Utilisez des blocs CIDR IPv4 privés définis par la norme RFC 1918 avec une longueur de masque de 16. Pour étendre l'espace d'adressage du VPC, ajoutez des blocs CIDR secondaires.
Si vous déployez vos services dans un seul VPC, réservez suffisamment d'adresses en spécifiant une longueur de préfixe plus petite.
Évitez les chevauchements de blocs CIDR lorsque vous créez plusieurs VPC pour votre activité.
Évitez les chevauchements de blocs CIDR lorsque vous créez plusieurs zones pour la reprise après sinistre.
À mesure que l'échelle du réseau augmente, la planification des blocs CIDR devient plus complexe. Utilisez IP Address Manager (IPAM) pour attribuer automatiquement des adresses IP et détecter les conflits d'adresses potentiels, améliorant ainsi l'efficacité de la planification des blocs CIDR. Pour plus d'informations, consultez IPAM.
Tenez compte des points suivants lors de l'utilisation d'IPAM :
Concevez des pools IPAM pour différents environnements, tels que les environnements de développement et de production.
Lorsque vous utilisez des pools IPAM pour allouer des blocs CIDR privés aux VPC, assurez-vous que les blocs CIDR des VPC ne se chevauchent pas.
Consultez les blocs CIDR des VPC et l'utilisation des adresses dans la console IPAM.
Planification du bloc CIDR du VPC
Utilisez des adresses IPv4 privées spécifiées dans la norme RFC 1918 pour les blocs CIDR IPv4 secondaires. La longueur de masque recommandée va de /16 à /28, par exemple 10.0.0.0/16, 172.16.0.0/16, 192.168.0.0/16. Vous pouvez également spécifier des blocs CIDR VPC personnalisés.
|
CIDR VPC |
Plage d'adresses IP |
|
|
|
|
|
|
|
|
|
Lorsque vous spécifiez des blocs CIDR pour les VPC, notez les règles suivantes :
Si vous ne disposez que d'un seul VPC et que celui-ci n'a pas besoin de communiquer avec un centre de données, spécifiez l'un des blocs CIDR RFC ou leurs sous-ensembles comme bloc CIDR du VPC.
Si vous disposez de plusieurs VPC ou si vous souhaitez mettre en place un environnement de cloud hybride entre un VPC et votre centre de données, évitez les conflits de blocs CIDR entre les VPC, ou entre un VPC et le centre de données.
Vous ne pouvez pas spécifier
100.64.0.0/10,224.0.0.0/4,127.0.0.0/8,169.254.0.0/16ou l'un de leurs sous-ensembles comme bloc CIDR personnalisé.Le choix d'un bloc CIDR VPC dépend également de l'utilisation du réseau classique. Si vous utilisez le réseau classique et prévoyez de connecter des instances ECS du réseau classique à votre VPC, ne spécifiez pas
10.0.0.0/8comme bloc CIDR du VPC, car le bloc CIDR du réseau classique est10.0.0.0/8.Vous pouvez utiliser IPAM pour planifier des pools et spécifier un masque réseau par défaut pour les allocations. Consultez l'utilisation des adresses d'un VPC à l'aide d'IPAM.
Planification des blocs CIDR des vSwitch
Le bloc CIDR d'un vSwitch doit être un sous-ensemble du bloc CIDR du VPC. Par exemple, si le bloc CIDR du VPC est 192.168.0.0/24, le masque réseau des vSwitch dans le VPC doit être compris entre /25 et /29.
Lorsque vous spécifiez des blocs CIDR pour les vSwitch, tenez compte des limites suivantes :
Le masque réseau du bloc CIDR IPv4 d'un vSwitch doit être compris entre /16 et /29, ce qui peut fournir de 8 à 65 536 adresses IP.
Le bloc CIDR du vSwitch ne peut pas être identique au bloc CIDR du VPC.
La planification des blocs CIDR des vSwitch doit prendre en compte le nombre d'instances ECS et d'autres ressources cloud qu'ils contiendront. Choisissez un bloc CIDR suffisamment grand pour réserver suffisamment d'adresses IP pour une utilisation ultérieure. Toutefois, n'allouez pas un bloc CIDR trop grand, car cela pourrait entraver la segmentation future du réseau.
Si vous créez un VPC avec le bloc CIDR
10.0.0.0/16, il prend en charge 65 536 adresses IP. Étant donné que vous devez déployer des ressources telles que ECS et RDS au sein des vSwitch, planifiez un masque/24pour vos vSwitch, chaque vSwitch prenant en charge 256 adresses IP. Un VPC avec le bloc CIDR10.0.0.0/16peut être divisé en un maximum de 256 vSwitch avec un masque/24. Ajustez si nécessaire.-
La première adresse et les trois dernières adresses de chaque bloc CIDR IPv4 d'un vSwitch sont réservées par le système. La première adresse et les neuf dernières adresses de chaque bloc CIDR IPv6 d'un vSwitch sont réservées par le système. Par exemple :
Version IP
CIDR vSwitch
Adresses IP réservées
IPv4
192.168.1.0/24192.168.1.0192.168.1.253192.168.1.254192.168.1.255IPv6
2001:XXXX:XXXX:1a00/642001:XXXX:XXXX:1a00::2001:XXXX:XXXX:1a00:ffff:ffff:ffff:fff72001:XXXX:XXXX:1a00:ffff:ffff:ffff:fff82001:XXXX:XXXX:1a00:ffff:ffff:ffff:fff92001:XXXX:XXXX:1a00:ffff:ffff:ffff:fffa2001:XXXX:XXXX:1a00:ffff:ffff:ffff:fffb2001:XXXX:XXXX:1a00:ffff:ffff:ffff:fffc2001:XXXX:XXXX:1a00:ffff:ffff:ffff:fffd2001:XXXX:XXXX:1a00:ffff:ffff:ffff:fffe2001:XXXX:XXXX:1a00:ffff:ffff:ffff:ffff Si plusieurs VPC sont déployés et qu'un vSwitch doit communiquer avec un autre vSwitch dans un VPC différent ou un centre de données, assurez-vous que le bloc CIDR du vSwitch ne chevauche pas le bloc CIDR pair. Sinon, la communication échouera.
La fonctionnalité ClassicLink permet aux instances ECS d'un réseau classique de communiquer avec des instances ECS dans un VPC dont le bloc CIDR est
10.0.0.0/8,172.16.0.0/12ou192.168.0.0/16. Si le bloc CIDR du VPC est10.0.0.0/8, le bloc CIDR du vSwitch appartenant au VPC doit être10.111.0.0/16. Pour plus d'informations, consultez Overview of ClassicLink.
Planification des tables de routage
Chaque entrée d'une table de routage est une route, qui se compose d'un bloc CIDR de destination, d'un type de saut suivant et d'un saut suivant. Une route dirige le trafic vers un bloc CIDR vers son saut suivant. Chaque VPC peut comporter jusqu'à 10 tables de routage, y compris la table de routage système. Reportez-vous aux recommandations suivantes pour planifier les tables de routage.
Utiliser une seule table de routage
S'il n'y a pas de différences significatives dans le routage du trafic entre les vSwitch de votre VPC, une seule table de routage suffit. Lorsque vous créez un VPC, le système crée automatiquement une table de routage système et y ajoute des routes système pour gérer le trafic du VPC. Vous ne pouvez pas créer ni supprimer la table de routage système, mais vous pouvez y ajouter des routes personnalisées pour diriger le trafic vers un bloc CIDR de destination.
Utiliser plusieurs tables de routage
Si les chemins de trafic des vSwitch sont significativement différents, par exemple pour restreindre l'accès à Internet de certains services cloud, vous pouvez utiliser plusieurs tables de routage. Vous pouvez déployer des vSwitch publics et privés. Les instances situées dans des vSwitch privés peuvent accéder à Internet via une passerelle NAT Internet, ce qui permet un contrôle unifié de l'accès à Internet et répond aux exigences d'isolation.
Chaque VPC prend en charge au maximum neuf tables de routage personnalisées. Pour augmenter le quota, accédez à la page Quota Management ou Quota Center.
Planification de la connectivité réseau
Alibaba Cloud fournit un réseau cloud sécurisé, isolé et évolutif, et prend en charge des connexions rapides entre le cloud et les centres de données. Utilisez un VPC pour accéder à Internet, à un autre VPC et à un centre de données. Combinez le VPC avec d'autres services pour une connectivité réseau adaptée à votre activité.
Accès à Internet
Tenez compte des points suivants lorsque vos applications doivent accéder à Internet ou être accessibles depuis celui-ci :
Configurez une adresse IP publique pour l'instance ECS, qui peut être une adresse IP publique statique ou une adresse IP élastique (EIP). Nous vous recommandons d'utiliser une EIP.
Si une seule instance ECS est utilisée pour fournir des services sur Internet, un point de défaillance unique (SPOF) peut survenir, affectant la disponibilité du système. Utilisez une instance Server Load Balancer (SLB) comme point d'entrée unifié du trafic Internet et associez plusieurs instances ECS à l'instance SLB. Cela permet d'éviter les SPOF et d'améliorer la disponibilité des services.
Si plusieurs instances ECS doivent accéder à Internet, utilisez la fonctionnalité SNAT d'une passerelle NAT Internet pour permettre aux instances ECS de partager des EIP et d'accéder à Internet. Cela permet d'économiser des adresses IP publiques.
Si vos instances ECS fournissent des services sur Internet, utilisez la passerelle IPv4 ou la passerelle IPv6 pour gérer l'accès à Internet des instances ECS de manière unifiée.
Connexion inter-VPC
Vous pouvez utiliser les services suivants pour activer la connectivité entre les VPC.
Si le nombre de VPC est inférieur ou égal à cinq, utilisez une connexion d'appairage VPC pour créer des connexions entre chaque paire.
Si votre architecture réseau est complexe avec de nombreux VPC, utilisez CEN pour gérer efficacement les VPC, faciliter l'O&M et garantir un transfert de données sécurisé.
Lorsque vous accédez à un service Alibaba Cloud tel que Object Storage Service (OSS) via Internet, des données sensibles peuvent être divulguées. Utilisez PrivateLink pour connecter le VPC où réside le endpoint et le VPC où réside le service endpoint, réduisant ainsi les risques de sécurité.
-
Utilisez une passerelle VPN pour établir une connexion sécurisée entre deux VPC, mais la latence réseau est élevée.
Cloud hybride
Utilisez les services suivants pour connecter un centre de données à un VPC.
Si vous exigez une sécurité élevée et une faible latence, utilisez des circuits Express Connect.
-
Si vous souhaitez réduire les coûts, utilisez une passerelle VPN.
Quelles sont les exigences pour les connexions VPC et le déploiement de cloud hybride ?
Pour connecter un VPC à un autre VPC ou à un centre de données, assurez-vous que les blocs CIDR ne se chevauchent pas. Suivez ces principes d'allocation par ordre de priorité :
CIDR VPC uniques. Attribuez un bloc CIDR unique et non chevauchant à chaque VPC. L'utilisation de sous-réseaux de plages RFC 1918 standard augmente le nombre de CIDR disponibles.
CIDR vSwitch uniques. Si vous ne pouvez pas garantir des blocs CIDR VPC uniques, assurez-vous que les blocs CIDR des vSwitch au sein des VPC communicants ne se chevauchent pas.
CIDR unique pour les vSwitch communicants. Si même les blocs CIDR des vSwitch se chevauchent, assurez-vous que les vSwitch qui doivent communiquer entre eux ont des blocs CIDR non chevauchants. La communication réseau échouera sinon.
Imaginez que vous disposiez de trois VPC dans différentes régions : VPC1 en Chine (Hangzhou), VPC2 en Chine (Pékin) et VPC3 en Chine (Shenzhen). Vous disposez également d'un centre de données sur site en Chine (Hangzhou).
VPC1 doit se connecter à VPC2 à l'aide d'une connexion d'appairage VPC.
VPC1 doit se connecter au centre de données sur site à l'aide d'Express Connect.
VPC3 n'a pas besoin de se connecter à quoi que ce soit pour le moment, mais pourrait avoir besoin de se connecter à d'autres VPC
IP Address Manager (IPAM) peut vous aider à gérer cela. Créez des pools distincts dans IPAM pour chaque région afin de garantir une allocation IP appropriée. Créez une allocation personnalisée et allouez 10.0.2.0/24 au centre de données. Cela permet d'éviter les conflits d'adresses IP et de s'assurer que les adresses IP ne seront pas utilisées de manière incorrecte.
Planification des capacités de sécurité
L'isolation de sécurité comprend l'isolation des services, des ressources et du réseau. Vous devez prendre en compte les exigences d'isolation de sécurité lors de la planification des régions, des zones, des comptes et des blocs CIDR. La séparation des comptes permet d'obtenir une isolation des ressources, tandis que la segmentation des VPC permet d'obtenir une isolation réseau. Ces deux méthodes permettent d'atteindre l'isolation métier. Planifiez vos capacités de sécurité en combinant les scénarios de connexion réseau avec une approche de sécurité en couches.
Niveau de sécurité | Suggestion |
Au sein du VPC | Si vous déployez plusieurs services dans un VPC, créez un vSwitch pour chaque service et utilisez des groupes de sécurité et des ACL réseau. |
Limite du VPC |
|
Utilisez les journaux de flux et la mise en miroir du trafic pour surveiller les VPC et résoudre les problèmes. Cela améliore la stabilité et la fiabilité du système.
|
Métrique |
Description |
|
Journal de flux |
Collectez des données de trafic et analysez les journaux de trafic pour optimiser la bande passante et éliminer les goulots d'étranglement réseau. |
|
Mise en miroir du trafic |
Mettez en miroir des paquets spécifiques transitant par les ENI pour l'inspection du contenu, la surveillance des menaces et le dépannage. |
Planification des capacités de reprise après sinistre
Planifiez des capacités de reprise après sinistre adaptées à votre architecture afin de garantir la sécurité des données et la disponibilité des services.
Si vous avez des exigences élevées en matière de reprise après sinistre, déployez des VPC sur plusieurs régions et des vSwitch sur plusieurs zones pour la reprise après sinistre.
Si votre service nécessite une réponse rapide, une concurrence élevée et une sécurité des données renforcée, utilisez SLB pour mettre en œuvre la récupération de cluster, la persistance de session et le déploiement inter-zones.
Utilisez des circuits Express Connect pour connecter vos centres de données aux VPC via des connexions rapides et stables. Cela garantit la synchronisation des données, prévient les SPOF et améliore la disponibilité des services.
Si vous avez des exigences élevées en matière de disponibilité des services, utilisez la fonctionnalité d'adresse IP virtuelle haute disponibilité (HaVip) conjointement avec Keepalived ou Heartbeat pour créer une architecture hautement disponible. Cela garantit que l'IP du service reste inchangée lors du basculement.
Prenez en compte les capacités de reprise après sinistre inhérentes aux services cloud eux-mêmes. Par exemple, RDS High-availability Edition Active utilise une architecture de haute disponibilité classique avec un nœud principal et un nœud de secours. Les nœuds principal et de secours peuvent être déployés dans la même zone ou dans des zones différentes au sein de la même région.
La figure suivante montre comment faire évoluer une architecture mono-zone vers une architecture actif/passif, offrant une sécurité et une disponibilité plus élevées.
Avant de créer un VPC, assurez-vous d'avoir pris en compte l'échelle actuelle de l'activité et l'expansion future, l'isolation de sécurité, la disponibilité des services et la reprise après sinistre, les coûts, le nombre de VPC et de vSwitch, ainsi que les blocs CIDR alloués aux VPC et aux vSwitch. Pour plus d'informations, consultez Création et gestion d'un VPC.