IaaS v1 - Guide pratique

attention

Si vous êtes un nouveau partenaire d'Evolution Platform, vous devez utiliser la dernière version de l'API IaaS pour les partenaires.

Bienvenue dans la documentation officielle de la version IaaS v1 d'Evolution Platform !
Ce document est conçu pour fournir une compréhension complète et détaillée des différents composants et fonctionnalités de notre Infrastructure en tant que Service (IaaS). À travers cette documentation, vous explorerez les principales APIs et les informations supplémentaires nécessaires pour gérer efficacement votre environnement virtuel. Les sections couvrent des sujets essentiels tels que les Réseaux Virtuels, les Politiques de Routage et les Machines Virtuelles.
Vous trouverez également des informations sur les Interfaces, la Résilience et les Blueprints pour des configurations spécifiques comme des VNFs simples connectés uniquement à Internet avec une IP flottante, ainsi que des VNFs résilientes.
Chaque section est accompagnée de résumés et d'orchestrations API pour vous guider dans la mise en œuvre et la gestion de ces composants. Cette documentation est un outil indispensable pour maximiser l'efficacité et la résilience de vos déploiements sur IaaS v1.

API principales / Informations supplémentaires

API	Description	Commentaires
Zone	Fournit des informations sur le POP SDN d'OINIS.	Informatif
Volume	Un volume est un dispositif de stockage amovible, similaire à un disque dur USB. Vous pouvez attacher un volume à une seule instance.	Devrait être optionnel mais est obligatoire pour le moment
VirtualNetwork	Réseau virtuel Openstack/Contrail pour interconnecter les VM via une couche 2 et/ou pour implémenter un VPN IP/MPLS (internet / VPN client, etc.).	Obligatoire
VirtualMachine	API principale pour créer une machine virtuelle.	Obligatoire
ServerGroup	En cas de VNF basée sur plusieurs VM, ServerGroup permet de regrouper les VM sur le même calcul ou de les séparer selon certaines politiques. - affinité : Les VM dans le même groupe de serveurs seront créées sur le même calcul. Si ce n'est pas possible, cela générera une erreur. - anti-affinité : Les VM dans le même groupe de serveurs seront créées sur des calculs différents. Si ce n'est pas possible, cela générera une erreur. - soft-[affinité|anti-affinité] : essaie de se conformer à la politique mais ne générera pas d'erreur si ce n'est pas possible.	Devrait être optionnel mais est obligatoire pour le moment
SecurityRule	Règle faisant partie d'un SecurityGroup.	Optionnel
SecurityGroup	Liste des ACL pour protéger une interface VM.	Optionnel. Disponible uniquement si le mode de transfert sur l'interface est défini sur flow. Cette fonctionnalité dépend de Contrail.
PublicIPAddress	Réserve et libère des adresses IP publiques pour la connectivité Internet.	Optionnel. Actuellement pris en charge uniquement via FloatingIPAddress (traduction d'adresse 1:1 entre l'adresse IP publique réservée via l'API et l'adresse IP "privée" d'une interface connectée à un réseau virtuel privé).
KeyPair	Générateur de paires de clés SSH à utiliser lors de la création de VM pour pousser un secret dans la VM grâce au mécanisme cloud-init. Il fournit un moyen sécurisé de générer une clé SSH directement sur l'IaaS au lieu de pousser un mot de passe via cloud-init.	Devrait être optionnel mais est obligatoire pour le moment
Interface	Utilisé pour manipuler l'interface VirtualMachine sans passer par l'API VirtualMachine complète.	Raccourci
Image	Image OS utilisée par la VM. L'utilisateur final pourra télécharger sa propre image avec un mécanisme de quota spécifique pour éviter les abus.
Flavor	Des flavors prédéfinis sont disponibles sur le POP SDN d'OINIS pour répondre aux principaux cas d'utilisation. Sur une base de service, des flavors supplémentaires peuvent être créés, en fonction des besoins marketing/commerciaux.	Informatif. La liste précise des flavors est encore à discuter avec les équipes NGH Indus. Il n'est pas prévu de laisser "l'utilisateur final" créer son propre flavor.

VirtualNetwork

L'API Virtual-Network est la principale pour configurer le réseau attaché à votre VM. Actuellement, seuls les réseaux virtuels privés locaux peuvent être créés.

• Privé : non partagé entre les projets
• Local : pas de connexion VPN IP/MPLS

Cette API permet de configurer le schéma d'adressage. Toutes les spécificités liées à la configuration des ports, au routage statique pour lequel il est considéré comme next hop ou aux fonctionnalités avancées telles que l'adresse IP flottante et la fonctionnalité VRRP sont effectuées via l'API virtual-machine.

Paramètres	Informations
subnet	Obligatoire. Sous-réseau au format CIDR, peut être IPv4 ou IPv6.
enableDhcp	Optionnel. true | false. La valeur par défaut est définie sur true.
allocateIpAddressFromStart	Optionnel. true | false. Le processus DHCP attribuera les adresses VM de manière séquentielle, de la première disponible à la dernière. La valeur par défaut est définie sur true.
dnsPrimary dnsSecondary	Optionnel. Serveur DNS à fournir dans la réponse DHCP lorsqu'une VM demande une adresse via DHCP. Pas de valeur par défaut.
gatewayIpAddress	Optionnel. Spécifie l'adresse du vRouter Contrail à utiliser pour son rôle de "passerelle". Par défaut : Contrail utilise la première adresse utilisable du sous-réseau. À confirmer par OINIS : il n'y a aucun moyen de faire en sorte que le vRouter agisse en tant que serveur DHCP et fournisse une autre adresse comme passerelle dans la réponse DHCP, ce sera l'adresse de la passerelle vRouter.
serviceIpAddress	Optionnel. Spécifie l'adresse que le vRouter doit utiliser pour configurer son interface dans ce VN. Par défaut : Contrail utilise la deuxième adresse utilisable du sous-réseau.

Politique de Routage

La Politique de Routage est un mécanisme pour manipuler la table de routage du réseau virtuel, en particulier lorsque le routage dynamique est utilisé soit avec les machines virtuelles (voir BGPaaS) soit pour une connexion L3VPN.

Ce mécanisme fournit des outils de manipulation de route standard et des filtres pour influencer le routage et implémenter des routages spécifiques (préférence locale, ajout de chemin AS, filtrage de route, etc.).

VirtualMachine

Interface

Adresse IP flottante :

L'adresse IP flottante est un mécanisme visant à rendre accessible un port VM connecté à un réseau virtuel privé depuis Internet. Le mécanisme repose sur la traduction d'adresses source et destination sur le vRouter Contrail. Un NAT 1:1 avec état est implémenté sur le vRouter Contrail qui modifie le trafic entrant et sortant pertinent.

Tout d'abord, une adresse IP doit être attribuée à partir d'un pool spécifique et associée à un port d'une machine virtuelle. Ce pool est routé sur Internet vers le POP SDN où il peut être utilisé. La configuration NAT sera une traduction d'adresse bidirectionnelle entre l'adresse IP flottante réservée et l'adresse IP configurée sur le port dans le réseau virtuel.

Limitations connues

• Disponible uniquement si le mode de transfert sur l'interface est défini sur flow. Cette fonctionnalité dépend de Contrail.
• Ne peut pas être utilisé avec le mécanisme AllowedIPAddressPair.

Architecture VNF Internet simple avec IP flottante.

Mode de transfert :

Deux modes de transfert existent sur le POP SDN d'OINIS :

• flow : Le vRouter Contrail maintient une table de flux pour suivre chaque flux traversant. Cela permet de mettre en œuvre des mécanismes avancés de Contrail tels que :
  • security-group
  • adresse IP flottante
  • autres mais non exposés via l'API
• packet : configuré sur une base par interface, désactive le mécanisme de suivi des flux et les fonctionnalités avancées associées qui nécessitent le mode flow.

Avantages du mode packet :

• Le PPS du vRouter est le seul facteur de mise à l'échelle puisqu'il n'y a pas de configuration de flux.
• Pas de DDoS sur le vRouter en raison de l'inondation TCP Syn par exemple (similaire à la limite de performance ci-dessus).

Avantages du mode flow :

• Fonctionnalités avancées telles que le groupe de sécurité pour protéger une interface exposée à un réseau non fiable tel qu'Internet.

Commentaires :

• OINIS doit confirmer sa recommandation en particulier avec l'évolution potentielle du POP SDN dans les prochains mois et le mode par défaut utilisé par l'interface.

Résilience

Le POP SDN ne fournit pas de mécanisme de résilience/HA d'infrastructure. Un tel mécanisme doit être apporté par le service au-dessus de l'infrastructure. Par exemple, un design typique consiste à déployer deux instances du service dans deux POP différents. En cas de problème sur le nominal, la logique du service basculera vers le backup. Cependant, l'IaaS derrière le POP SDN fournit deux mécanismes qui peuvent aider à créer un premier niveau de mécanisme de résilience :

• Affinité de groupe de serveurs pour déployer les VM sur des nœuds de calcul différents.
• "allowedIpAddressPairs" de serveur pour utiliser un mécanisme de type VRRP.

Architecture anti-affinité de groupe de serveurs.

Limitations connues

• Disponible uniquement si le mode de transfert sur l'interface est défini sur flow. Cette fonctionnalité dépend de Contrail.
• Ne peut pas être utilisé avec le mécanisme d'adresse IP flottante.

Blueprints

VNF simple connecté uniquement à Internet / IP flottante

Synopsis

Un simple VNF unique est créé avec :

• une seule interface connectée à un réseau privé où DHCP est activé. DHCP fournira :
  • une adresse dynamique dans le sous-réseau
  • une route par défaut pour aller au-delà du sous-réseau : internet ou un VPN attaché
  • un serveur DNS
• une IP flottante est utilisée pour fournir une connectivité Internet, un NAT 1:1 sera configuré par le vRouter.

Considérations de routage

La VM est connectée à un seul réseau virtuel et aucun routage dynamique n'est configuré. Lorsque la VM obtient sa configuration réseau via DHCP, elle apprendra la route par défaut. La route par défaut sera le vRouter Contrail dans le sous-réseau (dans ce blueprint, la première adresse utilisable).

Considérations de sécurité :

Dans l'exemple, aucun groupe de sécurité n'est appliqué, tout le trafic provenant d'Internet vers l'adresse IP publique sera envoyé à la VM. Par conséquent, des mécanismes de sécurité doivent exister dans la VM pour prévenir la corruption.

Exemple de cas d'utilisation correspondant :

Architecture de publication Netskope.

Orchestration API

Une fois le design terminé, certains paramètres sont nécessaires :

Paramètre	Recommandation
Project ID	ID du projet client
Zone	Nom public du POP SDN sur lequel nous voulons créer le VNF
VN Name	Peut être fixé par l'ingénierie du service. En gros, nous ne devrions pas avoir deux noms de VN dupliqués dans un projet.
Subnet of the VN	Paramètres d'ingénierie, dépendent du service. En général, ne doit pas chevaucher le plan d'adressage du client. C'est une bonne chose de proposer un sous-réseau par défaut qui conviendra à 90 % des cas et de laisser le client le personnaliser si nécessaire.
Public IP address	Ne peut pas être devinée, doit être réservée grâce à l'API.
VM Name	Peut être fixé par l'ingénierie du service. En gros, nous ne devrions pas avoir deux noms de VM dupliqués dans un projet.
Forwarding mode	Paramètre d'ingénierie, doit être choisi par l'ingénierie du service.

VNF résilient sur deux unités de calcul

Synopsis

Architecture VNF résiliente sur deux unités de calcul.