NSX - FAQ

Tous les packs sont basés sur un décompte jours/heures, par exemple : 1 jour = 8 heures, 2 jours = 16 heures (parfois plus). La première approche est la même pour tous les packs avec une phase de découverte, mais la durée du pack dépendra de la complexité de l'environnement et de la maturité de votre offre managée actuelle. Cette question sera étudiée avec les équipes Professional Services lors d'un premier appel d'évaluation.

Vous sécurisez vos flux avec le Distributed Firewall (sécurisation Nord/Sud ou Est/Ouest) de NSX ou utilisez l'un des Gateway Firewalls (sécurisation Nord/Sud).

VMware a décidé d'initier la fin de vie (EOL) de NSX-v depuis janvier 2022. OVHcloud a obtenu une extension de support jusqu'au 15 janvier 2025.

Il est impossible de faire du BGP public (peer avec les routeurs internet OVHcloud). Il est toutefois possible de faire du BGP (privé) avec un vRack via une passerelle Tier-0 ou une passerelle VRF de niveau 0, ou dans un tunnel IPsec via une Tier-0 uniquement.

Oui, à travers une VRF.

Il est possible de positionner des AS numbers privés différents selon les passerelles Tier-0 ou les passerelles VRF de niveau 0.

Vous pouvez tout à fait déconnecter les interfaces publiques de la T0 et interconnecter celles-ci via un réseau privé ou une appliance de sécurité exposée en direct sur internet. Notez qu'il existe dans la T0 un firewall intégré configurable via l'interface NSX, Gateway Firewall.

Dans la conception VMware, une Tier-1 est toujours attachée à une Tier-0. Les flux passent par une Tier-0 pour aller au réseau externe. Tous les éléments devant rester à l'intérieur (en local) de la plateforme Vsphere managée sont routés par la Tier-1.

Il est actuellement impossible d'ajouter une nouvelle Tier-0 Gateway. Selon les besoins, il est possible de créer une instance virtuelle de Tier-0 appelée VRF. Cette VRF ne pourra pas être connectée sur internet.

C'est impossible par défaut. Les Tier-0 Gateways sont hébergées chacune sur un host différent, HA (High Availability) est activée et une IP virtuelle (VIP) est configuré entre les 2 EDGES afin de maintenir la continuité de service. La partie HA est déjà préconfigurée par OVHcloud.

Non, c'est impossible par défaut, la configuration est gérée par OVHcloud et se fait en mode actif/passif avec un VIP (10 Gbp/s de bande passante garantie).

Non, c'est impossible, que ce soit pour des informations sur Tier-0 ou Tier-1. Il existe dans NSX des outils de troubleshooting.

Cette information dépend de la version de NSX en production sur l'infrastructure. Les valeurs maximales se trouvent sur le site Broadcaom dédié : https://configmax.broadcom.com/home.

L'ajout d'IP publiques supplémentaires peut se faire via le routage "next hop" en spécifiant comme ressource l'environnement VMware Hosted Private Cloud et en next hop l'IP virtuelle (VIP) publique de la Tier-0 (T0).

Les blocs d'adresses IP sont dépendants de l'environnement VMware Hosted Private Cloud et non du Datacenter virtuel. Il est donc possible d'utiliser le même bloc d'adresses IP entre plusieurs datacentres virtuels (sans aucune modification). Attention, si vous disposez de plusieurs Datacenters virtuels, un bloc d'IP publiques routé sur l'IP virtuelle (VIP) de votre Tier-0 (T0) ne pourra pas être utilisé dans un VM Network d'un autre Datacenter virtuel. Il est attaché à la VIP et non plus au VM Network.

Vous trouverez, dans le guide de migration, comment déplacer votre IP existante depuis votre plateforme NSX-v et la router vers l'IP attachée à la partie Tier-0 (T0). Lorsqu’un Datacenter Virtuel NSX-T est livré, nous déployons et configurons un nouveau bloc IP pour NSX Tier-0 (T0) que nous dédions à la VIP. C'est vers cette VIP que vous pourrez router le bloc IP.

Le datastore global est géré au niveau de l'espace client ou de l’API OVHcloud. Cela vous permet de globaliser votre datastore qui sera visible depuis votre nouveau vDC. Il vous permet de faire un Compute vMotion et non un Storage vMotion des machines virtuelles. Il n'est pas possible de le sortir de ce mode. Il vous faudra commander un nouveau datastore et y appliquer un vMotion pour le libérer globalement.

• Premiers pas avec NSX
• VMware on OVHcloud

Dans ce cas, vous n'avez pas besoin de commander un nouveau vDC, mais assurez-vous de désactiver toutes vos fonctionnalités NSX-v afin que OVHcloud puisse désactiver le composant.

La migration d'IP est effectuée par bloc, vous changez le next stop du bloc IP, le bloc global est transitionné vers la partie NSX.

Cela dépendra des services utilisés. Par exemple, si vous utilisez des tunnels IPSEC et des IP publiques, vous devrez déplacer vos workloads et reconfigurer le bloc IP que vous aviez sur votre infrastructure NSX-v vers votre infrastructure NSX-T. Si vous utilisez NSX-v pour du firewalling, vous pouvez avoir la configuration sur les 2 environnements. Le temps d'arrêt dépend donc de la complexité de votre environnement.

Cela dépendra des services activés (LoadBalancer/NAT/Firewall, etc.). Les débits et maximums sont dépendants de la version de NSX et disponibles sur le site de Broadcom.

Oui, le vRack fonctionne avec NSX-T. Vous avez la possibilité d'y accéder de la même manière à partir de portgroups vlan dans vSphere ou à partir de segments VLAN dans NSX-T.

Le cluster de NSX Edges est bien compatible avec un vRack OVHcloud. Vous pouvez ajouter votre Datacenter virtuel qui porte NSX-T dans le vRack de votre choix. Retrouvez plus d'informations sur cette page.

Non, la gestion des NSX Edges est effectuée par OVHcloud en mode Actif Passif.

Aujourd'hui, 1 seul cluster NSX-T Edge est déployé.

Le dimensionnement dépendra des services que vous activerez ou consommerez sur vos edges (firewall ou load balancing...). Aujourd'hui, les Edge sont de taille Medium. Les maximums et dimensionnements sont disponibles sur le site de Broadcom.

Il faut utiliser cette route, après avoir récupéré le cluster ID que vous venez de créer.

Oui, il est possible de le faire, voici un exemple des appels API que vous pouvez utiliser au sein de l'univers /dedicatedcloud : Récupérer le Edge ID :

Vous pouvez par exemple tester la résilience en simulant la panne d'un des nodes Edge du cluster :

Oui, mais il faudra les reconfigurer après la migration de votre Datacenter virtuel.

Il est possible d'obtenir NSX-T si vous commandez un nouveau Datacenter virtuel dans votre Hosted Private Cloud. Vous aurez donc au sein de la même infrastructure 2 Datacenters virtuels, l'un avec NSX-v et l'autre avec NSX-T. Veuillez noter que la commande du nouveau vDC déclenchera automatiquement le mécanisme de remboursement pour le mois à venir.

Cet outil nécessite des droits d'administration très forts sur l'environnement, l'équipe Professional Services peut valider l'exécution et la duplication. Dans cet outil, il est important de noter que de nombreux éléments ne sont pas pris en charge (options, règles existantes dans NSX-v). La phase de reproduction nécessiterait beaucoup d'adaptations de votre part, ce n'est donc pas un outil recommandé dans la migration chez OVHcloud.

L'interface NSX est indépendante et non liée à l'interface de vSphere. C'est pourquoi nous avons créé un endpoint dédié pour l'atteindre.

Oui, c'est possible, via le vRack par exemple, ou via le réseau public et les VIP des Edges Cluster.

Oui, OVHcloud réalise des sauvegardes. Cette sauvegarde n'est pas destinée à la restauration lors d'une mauvaise manipulation, mais de support en cas d'incident des différents contrôleurs NSX-T.

Oui, c'est possible, il n'y a pas de contraintes actuellement.

Il n’y a pas de limitations supplémentaires par rapport à un environnement non qualifié SecNumCloud.

Il n'existe pas de différence entre les sauvegardes dans les environnements qualifiés SecNumCloud et non SecNumCloud.

OVHcloud vous remboursera 1 mois pour le datacenter virtuel ajouté sur votre prochaine facture après la commande (1 mois = 30 jours).

Non, ces fonctionnalités ne sont pas incluses.

Oui.