Modèle d'architecture pour les topologies NSX multisites
VMware Cloud Foundation for Classic - Automated offrent une topologie NSX standard avec un seul cluster NSX en périphérie, qui comprend une seule passerelle Tier-0 ( T0 ) et Tier-1 ( T1 ). Vous disposez de plusieurs options pour créer et personnaliser des topologies de superposition multisite. Vous pouvez provisionner manuellement de nouveaux clusters de périphérie NSX et déployer de nouvelles passerelles Tier-0 ( T0 ) et Tier-1 ( T1 ) après le déploiement initial en suivant la documentation VMware NSX™.
Les informations suivantes fournissent quelques exemples de la manière dont ces topologies peuvent être adaptées à vos besoins.
Le déploiement automatisé fournit un seul cluster NSX workload edge avec deux nœuds de transport edge. Les topologies multisites nécessitent plus de nœuds et de clusters de transport NSX Edge. Vous pouvez les déployer manuellement après le déploiement à l'aide d'adresses IP privées IBM Cloud pour la gestion de périphérie et les TEP.
Multisite à locataire unique
Le multisite à locataire unique est un cas d'utilisation courant et un modèle de déploiement du réseau. Cette topologie permet une récupération transparente des sites à l'aide de protocoles de routage dynamiques, tels que BGP. L'automatisation du serveur vCenter ne déploie pas automatiquement la topologie multi-site. Toutefois, vous pouvez personnaliser la topologie à site unique par défaut après le déploiement initial du serveur vCenter. Lorsque vous disposez de la capacité de traitement dans le centre de données requis, vous pouvez déployer manuellement les noeuds supplémentaires requis. Ensuite, créez un nouveau cluster de périphérie pour les passerelles Tier-0 et Tier-1 via NSX. Cette topologie de superposition est hautement évolutive et il est possible de l'automatiser, par exemple, en utilisant Ansible et Terraform.
Le diagramme suivant montre un exemple de topologie de réseau multisite à locataire unique. Il s'agit d'un modèle à deux couches Tier-0 avec trois groupes de bords. Deux clusters de périphérie dans les deux centres de données ou zones d'une région multizone, et un cluster de périphérie déployé dans la région multizone avec des noeuds de périphérie dans chaque zone ou centre de données participant.
- L'automatisation vCenter Server déploie une solution de site unique, qui peut être développée manuellement pour prendre en charge la topologie multi-site cible. Le déploiement comprend un seul site vCenter et trois gestionnaires NSX qui sont déployés dans le cluster sur le site initial du centre de données IBM Cloud. Vous devez développer la capacité de traitement pour disposer des ressources disponibles dans l'autre centre de données ou zone IBM Cloud dans la région multi-zone IBM Cloud spécifique.
- L'automatisation du serveur vCenter Server déploie deux nœuds de transport de cluster de périphérie et un cluster de périphérie unique pour vos passerelles Tier-0 et Tier-1. Vous n'avez pas besoin de la passerelle Tier-1 par défaut, et elle peut être supprimée.
- Dans le centre de données initial IBM Cloud, l'accès au réseau privé est assuré par des liaisons montantes privées. Ils sont connectés à un sous-réseau portable sur un réseau local virtuel privé principal sur le réseau privé IBM Cloud. Si vous approvisionnez votre instance avec des interfaces publiques, l'accès au réseau public est fourni par des liaisons montantes publiques. Ils sont connectés à un sous-réseau portable sur un réseau local virtuel sur le réseau public IBM Cloud. Les liaisons montantes possèdent des adresses IP spécifiques à ce centre de données et elles ne peuvent pas se déplacer entre les centres de données.
- Vous devez déployer manuellement deux noeuds de transport de cluster supplémentaires. Vous devez également créer un cluster de périphérie pour vos passerelles Tier-0 et Tier-1 dans le deuxième hôte de centre de données IBM Cloud.
- Dans le deuxième centre de données IBM Cloud, l'accès au réseau privé est assuré par des liaisons montantes privées. Ils sont connectés à un sous-réseau portable sur un réseau local virtuel privé principal sur le réseau privé IBM Cloud. Si vous approvisionnez votre instance avec des interfaces publiques, l'accès au réseau public est fourni par des liaisons montantes publiques. Ils sont connectés à un sous-réseau portable sur un réseau local virtuel sur le réseau public IBM Cloud. Les liaisons montantes possèdent des adresses IP spécifiques à ce centre de données et elles ne peuvent pas se déplacer entre les centres de données.
- Vous devez déployer manuellement deux nœuds de transport de cluster de périphérie ou plus dans le cluster de périphérie régional, au moins un dans chaque zone ou centre de données pour la haute disponibilité (HA). Créez ensuite un cluster de bords à l'aide de ces nœuds de transport de bord et créez votre Tier-0 régional dans ce cluster. Vous pouvez sélectionner le centre de données (ou le noeud de bord) qui correspond à votre chemin Tier-0 préféré dans le cluster régional.
- Créez un transit de superposition et des liaisons montantes dans les passerelles Tier-0 dans le segment de transit. Établissez un routage dynamique entre les passerelles Tier-0 et BGP. Il s'agit du protocole de routage préféré.
- Créez ensuite vos passerelles Tier-1 dans le cluster de périphérie régional. Vous pouvez sélectionner le centre de données (ou le noeud de bord) qui correspond à votre chemin Tier-1 préféré dans le cluster régional.
- Vous pouvez connecter vos segments à ce niveau de passerelles Tier-1. De plus, vous pouvez créer plusieurs segments et les annoncer via Tier-1 Gateway vers les passerelles Tier-0 de destination nord.
Cet exemple de topologie de réseau ne tient pas compte du plan de gestion et de contrôle (vCenter et NSX Managers). Le plan de contrôle de l'AH est abordé dans un autre modèle de disponibilité.
La principale raison pour laquelle vous avez besoin de deux couches est la connectivité physique nord-sud dans les centres de données et chaque centre de données ayant ses propres réseaux locaux virtuels privés et publics et les adresses IP pour les liaisons montantes. Ces adresses IP ne peuvent pas se déplacer entre les centres de données. Par conséquent, vous devez prendre en compte le routage et la conversion d'adresse réseau si vous utilisez la connectivité publique dans cette topologie.
Multisite multitenant
Le multilocataire multisite est un cas d'utilisation et un modèle de déploiement de réseau dans lequel les locataires ont besoin d'une solution avec des espaces IP conflictuels et une isolation complète de la table de routage. Cette topologie permet une récupération transparente des sites à l'aide de protocoles de routage dynamiques, tels que BGP. L'automatisation du serveur vCenter ne déploie pas automatiquement la topologie multi-site. Toutefois, vous pouvez personnaliser la topologie à site unique par défaut après le déploiement initial du serveur vCenter. Lorsque vous disposez de la capacité de traitement dans le centre de données requis, vous pouvez déployer manuellement les noeuds supplémentaires requis. Ensuite, créez un nouveau cluster de périphérie pour les passerelles Tier-0 et Tier-1 via NSX. Cette topologie de superposition est hautement évolutive et il est possible de l'automatiser, par exemple, en utilisant Ansible et Terraform.
Le diagramme suivant présente un exemple de topologie multi-site - multi-locataires. Il s'agit d'un modèle à deux couches Tier-0 avec trois groupes de bords. La séparation de la table de routage est effectuée à l'adresse Tier-1 et, éventuellement, au niveau régional Tier-0. Deux clusters de périphérie dans les deux centres de données ou zones d'une région multizone, et un cluster de périphérie déployé dans la région multizone avec des noeuds de périphérie dans chaque zone ou centre de données participant.
{: caption="NSXExemple de " caption-side="bottom"} multitenant multisite
- L'automatisation vCenter Server déploie une solution de site unique, qui peut être développée manuellement pour prendre en charge la topologie multi-site cible. Le déploiement comprend un seul site vCenter et trois gestionnaires NSX qui sont déployés dans le cluster sur le site initial du centre de données IBM Cloud. Vous devez développer la capacité de traitement pour disposer des ressources disponibles dans l'autre centre de données ou zone IBM Cloud dans la région multi-zone IBM Cloud spécifique.
- L'automatisation du serveur vCenter Server déploie deux nœuds de transport de cluster de périphérie et un cluster de périphérie unique pour vos passerelles Tier-0 et Tier-1. Vous n'avez pas besoin de la passerelle Tier-1 par défaut, et elle peut être supprimée.
- Dans le centre de données initial IBM Cloud, l'accès au réseau privé est assuré par des liaisons montantes privées. Ils sont connectés à un sous-réseau portable sur un réseau local virtuel privé principal sur le réseau privé IBM Cloud. Si vous approvisionnez votre instance avec des interfaces publiques, l'accès au réseau public est fourni par des liaisons montantes publiques. Ils sont connectés à un sous-réseau portable sur un réseau local virtuel sur le réseau public IBM Cloud. Les liaisons montantes possèdent des adresses IP spécifiques à ce centre de données et elles ne peuvent pas se déplacer entre les centres de données.
- Vous devez déployer manuellement deux noeuds de transport de cluster supplémentaires et créer un cluster de périphérie pour vos passerelles Tier-0 et Tier-1 dans le deuxième hôte de centre de données IBM Cloud.
- Dans le deuxième centre de données IBM Cloud, l'accès au réseau privé est assuré par des liaisons montantes privées. Ils sont connectés à un sous-réseau portable sur un réseau local virtuel privé principal sur le réseau privé IBM Cloud. Si vous approvisionnez votre instance avec des interfaces publiques, l'accès au réseau public est fourni par des liaisons montantes publiques. Ils sont connectés à un sous-réseau portable sur un réseau local virtuel sur le réseau public IBM Cloud. Les liaisons montantes possèdent des adresses IP spécifiques à ce centre de données et elles ne peuvent pas se déplacer entre les centres de données.
- Vous devez déployer manuellement deux nœuds de transport de cluster de périphérie ou plus dans le cluster de périphérie régional, au moins un dans chaque zone ou centre de données pour HA. Créez ensuite un cluster de bords à l'aide de ces nœuds de transport de bord et créez votre Tier-0 régional dans ce cluster. Vous pouvez sélectionner le centre de données (ou le noeud de bord) qui correspond à votre chemin Tier-0 préféré dans le cluster régional. Vous pouvez séparer les tables de routage à ce niveau en utilisant la fonction VRF lite dans la passerelle Tier-0. Pour plus d'informations, voir la documentation de Broadcom®.
- Créez manuellement un segment de transit de superposition et créez des liaisons montantes dans les passerelles Tier-0 dans le segment de transit. Etablissez un routage dynamique entre les passerelles Tier-0 et BGP est le protocole de routage préféré. Si vous utilisez la fonction VRF lite dans Tier-0 Gateway, vous pouvez utiliser plusieurs segments de transit en fonction de votre conception.
- Créez ensuite vos passerelles Tier-1 dans le cluster de périphérie régional. Vous pouvez sélectionner le centre de données (ou le noeud de bord) qui correspond à votre chemin Tier-1 préféré dans le cluster régional. Vous pouvez séparer les tables de routage à ce niveau et décider des routes qui font l'objet d'une publicité pour la liaison nord Tier-0. Comme dans les autres modèles multi-locataires, vous pouvez également utiliser NAT.
- Vous pouvez connecter vos segments à ce niveau de passerelles Tier-1. Vous pouvez créer plusieurs segments et les annoncer via la passerelle Tier-1 vers les passerelles Tier-0 en direction du nord.
Cet exemple de topologie de réseau ne tient pas compte du plan de gestion et de contrôle (vCenter et NSX Managers). Le plan de contrôle de l'AH est abordé dans un autre modèle de disponibilité.
Les passerelles Tier-0 prennent en charge VRF lite, qui peut être utilisé si nécessaire pour prendre en charge des topologies plus complexes pour l'isolation des tables de routage également au niveau Tier-0. Pour plus d'informations sur les capacités et les limitations, consultez la documentation NSX de VMware.
La principale raison pour laquelle vous avez besoin de deux couches est la connectivité physique nord-sud dans les centres de données et chaque centre de données ayant ses propres réseaux locaux virtuels privés et publics et les adresses IP pour les liaisons montantes. Ces adresses IP ne peuvent pas se déplacer entre les centres de données. Par conséquent, vous devez prendre en compte le routage et la conversion d'adresse réseau si vous utilisez la connectivité publique dans cette topologie.
Remarques sur la sélection d'une topologie de réseau de fond de page
VMware NSX™ propose de nombreuses façons de construire les topologies de réseau, et la topologie de réseau par défaut est utile pour de nombreux cas d'utilisation. Vous pouvez en général commencer par cela, et le développer au fur et à mesure de la croissance de vos besoins. Une fois le déploiement initial effectué, IBM Cloud automation utilise la topologie de superposition des charges de travail et vous pouvez modifier l'exemple de topologie en fonction de vos besoins. Lors de la modification de la configuration, les liaisons montantes par défaut fournissent la connectivité routée de base aux réseaux privés et publics IBM Cloud. Si vous modifiez les adresses IP ou le routage, vos charges de travail de superposition risquent de perdre leur connectivité.
IBM Cloud offre un moyen flexible de construire la topologie NSX en fonction de vos besoins. Lorsque vous concevez votre propre solution de réseau superposé, il est important de savoir que vous pouvez déployer manuellement de nouveaux nœuds de périphérie NSX et de nouveaux clusters de périphérie NSX. Pensez également à utiliser Ansible et Terraform pour atteindre vos objectifs. Vous pouvez le faire en suivant la documentation et les directives de conception de Broadcom après le déploiement initial.
La majeure partie du contenu des guides de conception et de la documentation de VMware NSX peut être appliquée à IBM Cloud. Prenons par exemple le nombre de réseaux locaux virtuels requis et l'utilisation du réseau local virtuel étendu dans la sous-couche entre les centres de données de la région multizone. De plus, le réseau privé IBM Cloud ne doit pas être considéré comme le haut du commutateur de l'armoire (ToR). Le routeur BCR (Backend Customer Router) ne fournit pas de support de routage dynamique (BGP) par défaut.