Google Cloud Platform pour les utilisateurs professionnels d'Azure : Mise en réseau

Mis à jour le 18 juillet 2017

Comparez les services de mise en réseau fournis par Azure et Google dans leurs environnements cloud respectifs. Les services de mise en réseau permettent de connecter des machines virtuelles, d'autres services cloud et des serveurs sur site.

Réseau virtuel

Réseaux et sous-réseaux

Azure et Cloud Platform fournissent tous deux des réseaux virtuels isolés. Les réseaux VNet Azure sont des ressources régionales, et les réseaux VPC Cloud Platform sont des ressources mondiales. Dans Azure et dans Cloud Platform, vous pouvez créer plusieurs réseaux au sein d'un projet ou d'un abonnement donné, puis segmenter ces réseaux en un ou plusieurs sous-réseaux. En outre, les VM déployées dans un réseau virtuel peuvent communiquer entre elles sans configuration supplémentaire, quel que soit le sous-réseau dans lequel elles se trouvent.

Sur Azure, vous ne pouvez réduire ou étendre la plage d'adresses IP de votre sous-réseau que si ce dernier ne contient pas encore de VM ou de services. En revanche, sur Cloud Platform, vous pouvez étendre la plage d'adresses IP de votre sous-réseau sans affecter les VM de celui-ci. Cependant, vous ne pouvez pas réduire un sous-réseau après l'avoir créé, ou après avoir étendu sa plage d'adresses IP.

Cloud Platform vous permet également de partager des réseaux virtuels entre des projets regroupés dans la même organisation cloud. Cette capacité est appelée mise en réseau VPC partagé. Avec le VPC partagé, les administrateurs de l'organisation cloud peuvent autoriser plusieurs projets à utiliser un même réseau virtuel partagé et les ressources réseau correspondantes. Pour en savoir plus sur le VPC partagé, consultez la Présentation des réseaux VPC partagés. Azure ne fournit pas de fonctionnalité comparable au VPC partagé.

Interfaces réseau et adresses IP

À première vue, les réseaux VPC et les réseaux virtuels Azure gèrent les adresses IP de la même manière. Au lancement, toutes les VM ont une adresse IP interne privée. Vous pouvez éventuellement associer une adresse IP externe à votre VM. Cette adresse IP peut être dynamique ou statique. Cependant, les détails de bas niveau de chaque service diffèrent légèrement.

Azure

Azure traite les interfaces réseau (cartes réseau) et tous les types d'adresses IP comme des ressources. Vous devez associer une ressource Adresse IP publique à une ressource Carte réseau qui est elle-même associée à une VM spécifique. Azure gère jusqu'à 32 cartes réseau par machine suivant le type de machine. Chaque carte réseau gère jusqu'à 50 configurations IP, chacune pouvant gérer une seule adresse IP publique et une seule adresse IP privée.

Par défaut, votre adresse IP publique est éphémère. Si vous dissociez une ressource Adresse IP publique d'une ressource Carte réseau, la ressource Adresse IP publique est conservée, mais l'adresse IP elle-même est supprimée. Si vous associez la ressource Adresse IP publique à une nouvelle VM, une nouvelle adresse IP est associée à la ressource.

L'adresse IP privée de votre VM est également éphémère. La VM abandonne son adresse IP privée lorsque vous l'arrêtez ou la mettez hors service, puis récupère une nouvelle adresse IP lorsque vous la redémarrez.

Vous pouvez également configurer votre adresse IP publique ou privée pour qu'elle soit statique. Si votre adresse IP est statique, elle est conservée même si la ressource Adresse IP est dissociée de toute carte réseau.

Compute Engine

Sur Compute Engine, les cartes réseau ne sont pas traitées comme des ressources distinctes. Au lieu de cela, elles sont directement liées à une instance de VM donnée. Les instances de VM Compute Engine gèrent jusqu'à huit cartes réseau suivant le type de machine. Chaque carte réseau gère une seule adresse IP externe et une seule adresse IP interne.

Comme avec Azure, Compute Engine attribue une adresse IP interne à chaque instance de VM. Vous pouvez associer une adresse IP externe éphémère ou statique. L'adresse IP interne et l'adresse IP externe éphémère font partie de votre instance de VM et ne constituent pas des ressources distinctes. Toutefois, si vous convertissez votre adresse IP externe éphémère en adresse statique, elle devient une ressource indépendante pouvant être dissociée de la VM.

Contrairement à Azure, l'adresse IP interne de votre instance de VM est réservée pour la durée de vie de l'instance.

Compute Engine vous permet également d'attribuer une plage d'adresses IP en tant qu'alias à l'adresse IP principale d'une instance de VM. Cette fonctionnalité vous permet d'attribuer des adresses IP distinctes à des services distincts exécutés sur la même instance de VM, ce qui la rend particulièrement utile pour les cas d'utilisation impliquant la conteneurisation. En outre, vous pouvez configurer une plage CIDR secondaire dans votre sous-réseau, qui peut être utilisée pour attribuer des adresses IP d'alias à ce sous-réseau.

Type d'adresse IP Azure Cloud Platform
Adresse IP permanente Adresse IP publique statique Adresse IP statique
Adresse IP temporaire Adresse IP publique dynamique Adresse IP éphémère
Adresse IP interne Adresse IP privée Adresse IP interne

Migration de VM

Azure gère automatiquement la migration de vos VM lorsque le matériel sous-jacent est en cours de mise à jour ou en panne. Bien que ce processus soit généralement simple, vous devrez parfois redémarrer votre VM pour que les mises à jour prennent effet. Dans de rares cas, Azure peut avoir besoin de forcer le redémarrage de votre VM.

De même, Cloud Platform propose une migration à chaud, au cours de laquelle Cloud Platform migre automatiquement et de manière transparente les instances de VM lorsque leur matériel hôte nécessite une opération de maintenance ou un remplacement. Comme pour le processus de migration d'Azure, la migration à chaud est généralement simple, mais peut dans de rares cas nécessiter un redémarrage de l'instance de VM. La migration à chaud est activée par défaut pour la plupart des types de machines. Toutefois, les machines dotées de GPU ne peuvent pas utiliser la migration à chaud, car les GPU sont directement associés au matériel hôte. Pour en savoir plus sur la fonctionnalité de migration à chaud, consultez cet article du blog.

Pare-feu

Azure et Compute Engine permettent aux utilisateurs de configurer des règles de pare-feu avec état pour autoriser et refuser de manière sélective le trafic vers les ressources en réseau. Dans les deux environnements, chaque réseau virtuel bloque par défaut tout le trafic entrant provenant de l'extérieur du réseau. Vous pouvez autoriser l'accès à une ressource spécifique en appliquant des règles. Sur Azure, chaque règle est configurée en tant que groupe de sécurité réseau (Network Security Group ou NSG) et, sur Compute Engine, chaque règle est configurée en tant que règle de pare-feu.

Dans Cloud Platform et Azure, vous pouvez associer des tags à vos NSG ou à des règles de pare-feu, ce qui vous permet d'appliquer les règles aux ressources utilisant un tag donné. Sur Azure, vous ne pouvez associer qu'un seul NSG à une carte réseau ou à un sous-réseau donné. En revanche, sur Cloud Platform, vous pouvez appliquer plusieurs règles de pare-feu à une ressource, permettant ainsi une gestion plus précise de votre pare-feu.

Azure permet également aux utilisateurs de configurer des règles de pare-feu sans état en créant des listes de contrôle d'accès (LCA) aux points de terminaison pouvant être appliquées au niveau de la VM. Cloud Platform ne gère pas les règles de pare-feu sans état.

Équilibrage de charge

Les équilibreurs de charge répartissent le trafic entrant sur plusieurs instances. Lorsqu'ils sont correctement configurés, les équilibreurs de charge rendent les applications tolérantes aux pannes et renforcent leur disponibilité.

Au niveau global, les composants d'équilibrage de charge d'Azure peuvent être comparés à ceux de Cloud Platform comme suit :

Composant Microsoft Azure Google Cloud Platform
Équilibrage de charge HTTP Application Gateway (peut être associé au gestionnaire du trafic pour un équilibrage de charge interrégional) Équilibreur de charge HTTP(S) de Compute Engine
Équilibrage de charge TCP/UDP Azure Load Balancer (équilibreur de charge Web) Équilibreur de charge réseau, équilibreur de charge proxy TCP (interrégional)
Équilibrage de charge interne Azure Load Balancer (équilibreur de charge interne) Équilibreur de charge interne de Compute Engine
Équilibrage de charge SSL Application Gateway (trafic HTTPS) Équilibreur de charge HTTP(S) de Compute Engine (trafic HTTPS), équilibreur de charge proxy SSL (trafic chiffré autre que HTTP)

Équilibrage de charge HTTP(S)

Azure et Compute Engine assurent un équilibrage de charge de niveau 7 distribuant les requêtes des clients au niveau de la couche d'application afin de réaliser un routage plus sophistiqué que ne le permet l'équilibrage de charge de niveau 4. Azure fournit ce service via Application Gateway, et Compute Engine fournit ce service via son équilibreur de charge HTTP(S). Ces services peuvent être comparés comme suit :

Fonctionnalité Application Gateway Équilibreur de charge HTTP(S) de Compute Engine
Équilibrage de charge HTTP Oui Oui
Adresse IP globale unique dans toutes les régions Non Oui (IPv4 et IPv6)
Équilibrage de charge interrégional Lorsqu'il est associé au gestionnaire du trafic (basé sur DNS) Disponible en mode natif (basé sur l'adresse IP)
Équilibrage de charge basé sur le contenu Oui Oui
Affinité de session Oui (basé sur les cookies) Oui (basé sur les cookies et sur l'adresse IP)
Terminaison SSL Oui Oui
SSL de bout en bout Oui Oui
Assistance WebSocket Oui Oui
Surveillance d'état Oui Oui
Journalisation Oui Oui (actuellement en version alpha)
Distribution de la charge Interrogation à répétition alternée Utilisation du processeur ou nombre de requêtes par seconde (RPS)
Autoscaling Non Oui

Équilibrage de charge HTTP(S) interrégional

Application Gateway et Compute Engine permettent d'assurer un équilibrage de charge HTTP(S) interrégional.

Sur Azure, vous pouvez configurer l'équilibrage de charge HTTP(S) interrégional en plaçant Traffic Manager, le service de routage du trafic basé sur DNS d'Azure, devant plusieurs points de terminaison Application Gateway. Traffic Manager achemine ensuite le trafic vers le point de terminaison Application Gateway le plus proche de l'utilisateur final suivant la stratégie de routage choisie.

Contrairement à Application Gateway, l'équilibrage de charge HTTP(S) de Compute Engine gère l'équilibrage de charge HTTP(S) interrégional de manière native. Lorsque vous créez votre équilibreur de charge HTTP(S), vous configurez une règle de transfert globale contenant un seul point d'entrée IP global. Cette règle envoie le trafic via un proxy cible qui le distribue aux backends correspondants. L'équilibreur de charge HTTP(S) dirige le trafic vers les backends les plus proches de l'utilisateur final. Toutefois, l'équilibrage de charge basé sur l'adresse IP globale de Compute Engine offre des gains de performance considérables :

  • L'équilibrage de charge basé sur l'adresse IP est sensible à la charge. Vous pouvez configurer l'équilibreur de charge global de Compute Engine pour distribuer le trafic en fonction de l'utilisation du processeur ou du nombre de requêtes par seconde. En revanche, l'équilibrage de charge basé sur DNS n'est pas sensible à la charge et doit acheminer le trafic en fonction de règles de routage générales.
  • L'équilibrage de charge basé sur DNS dépend des fournisseurs d'accès Internet (FAI). Pour qu'une modification DNS prenne effet, elle doit être enregistrée au niveau du FAI. Étant donné que les FAI mettent souvent en cache les enregistrements DNS pour une durée de plusieurs heures, ils risquent de ne pas enregistrer vos modifications DNS à temps, ce qui entraîne l'acheminement de vos utilisateurs finaux vers un service de backend surexploité, voire défaillant. L'équilibrage de charge global basé sur l'adresse IP peut vous aider à éviter cette source de problèmes potentiels.

Affinité de session

L'affinité de session vous permet de mapper un client spécifique sur un backend spécifique, économisant ainsi potentiellement les ressources côté serveur.

Application Gateway fournit une affinité de session basée sur les cookies, qui associe un client à une VM backend spécifique en stockant un cookie côté client.

L'équilibreur de charge HTTP(S) de Compute Engine fournit également une affinité basée sur les cookies. En outre, l'équilibreur de charge HTTP(S) fournit une affinité basée sur l'adresse IP, qui transfère toutes les requêtes d'une adresse IP client spécifique vers la même instance de VM.

Scaling

Sur Application Gateway, vous devez ajouter manuellement des VM lorsque la capacité de diffusion de votre équilibreur de charge est dépassée. En revanche, l'équilibreur de charge HTTP(S) de Compute Engine offre un autoscaling des instances de VM basé sur la capacité de diffusion de l'équilibreur de charge, ce qui vous permet de gérer le débordement du trafic sans intervention manuelle. Cet autoscaling se produit instantanément, sans préchauffage. Pour en savoir plus, consultez la page Équilibrage de charge et scaling.

Équilibrage de charge TCP/UDP

Azure et Compute Engine assurent un équilibrage de charge de niveau 4, qui distribue les requêtes des clients dans une région située au niveau de la couche de transport en réseau. Azure fournit ce service via Azure Load Balancer, et Cloud Platform fournit ce service via l'équilibreur de charge réseau de Compute Engine.

Ces services peuvent être comparés comme suit :

Fonctionnalité Azur Load Balancer Équilibreur de charge réseau de Compute Engine
Équilibrage de charge TCP/UDP Oui Oui
Équilibrage de charge interne Oui Oui
Équilibrage de charge Web Oui Oui
Protocoles de couche d'application disponibles Tous Tous
Points de terminaison disponibles VM Azure (à l'exception des VM de base), instances de rôles Cloud Services Pools cibles, instances de VM cibles, services backend (équilibrage de charge interne uniquement)
Surveillance d'état Oui Oui
Mode d'équilibrage de charge par défaut 5-tuple (IP source et IP de destination, ports source et de destination, type de protocole) 5-tuple (IP source et de destination, ports source et de destination, type de protocole)
Modes d'affinité de session 2-tuple (IP source et de destination), 3-tuple (IP source et de destination, port) 2-tuple (IP source et de destination), 3-tuple (IP source et de destination, type de protocole)

Équilibrage de charge TCP/UDP interrégional

Sur Azure, vous pouvez améliorer la latence des utilisateurs finaux en plaçant le Traffic Manager devant vos équilibreurs Azure Load Balancer, en le configurant pour le routage dynamique vers leurs adresses IP publiques. Cet agencement vous permet d'utiliser une seule configuration DNS pour acheminer le trafic vers les VM les plus proches de vos utilisateurs.

Sur Compute Engine, vous pouvez obtenir des résultats similaires en configurant l'équilibrage de charge du proxy TCP ou l'équilibrage de charge du proxy SSL. La conception de ces services est semblable à celle de l'équilibreur de charge HTTP(S) de Compute Engine, mais elle gère un plus grand nombre de protocoles de couche applicative. Comme avec l'équilibreur de charge HTTP(S), les deux services vous permettent d'utiliser une seule adresse IP globale pour distribuer le trafic vers les instances de VM les plus proches de vos utilisateurs.

L'équilibrage de charge basé sur l'adresse IP offre des gains de performance considérables par rapport à l'équilibrage de la charge basé sur DNS, en particulier une distribution du trafic basée sur la charge et des performances plus constantes. Consultez la page Équilibrage de charge HTTP(S) interrégional pour en savoir plus.

Coûts

Les frais relatifs à Azure Load Balancer sont inclus dans le prix des machines virtuelles Azure.

Application Gateway facture un tarif horaire pour chaque passerelle et un tarif distinct par Go pour le trafic traité via la passerelle.

Compute Engine facture un tarif horaire pour chaque règle de transfert et un tarif distinct par Go pour le trafic traité via l'équilibreur de charge.

DNS

Un service DNS permet de traduire des noms de domaines lisibles en adresses IP utilisées par les serveurs pour se connecter entre eux. Les services DNS gérés, tels que Azure DNS et Google Cloud DNS, offrent un DNS géré évolutif dans le cloud.

Azure DNS et Cloud DNS sont très similaires. Les deux gèrent les types d'enregistrements DNS les plus courants, ainsi que la diffusion basée sur Anycast. Aucun des deux services n'est actuellement compatible avec DNSSEC.

Connectivité

Les services de connectivité d'Azure peuvent être comparés à ceux de Cloud Platform comme suit :

Fonctionnalité Azure Cloud Platform
Appairage de VPC Appairage de VNet Appairage de réseaux VPC
Réseau privé virtuel Passerelles VPN Azure Cloud VPN
Connexion privée dédiée via un partenaire opérateur ExpressRoute Non applicable
Connexion publique dédiée via un partenaire opérateur ND Carrier Interconnect
Connexion directe dédiée ND Appairage direct
Appairage CDN ND CDN Interconnect

VPN

Azure et Cloud Platform fournissent tous deux un service de réseau privé virtuel (VPN). Azure propose Azure VPN Gateway, et Cloud Platform offre Google Cloud VPN dans Compute Engine. Dans chaque service, vous créez un tunnel d'un réseau externe vers votre réseau virtuel Azure ou Compute Engine interne, puis vous établissez une connexion sécurisée sur ce tunnel.

Pour acheminer le trafic sur Cloud Platform, vous pouvez utiliser Google Cloud Router, qui permet des mises à jour du routage dynamique BGP entre votre réseau Compute Engine et votre réseau autre que Google. Azure propose un service de routage similaire dans le cadre du service Azure VPN Gateway.

Appairage de réseaux virtuels

Azure et Cloud Platform offrent la possibilité d'appairer un ou plusieurs réseaux virtuels. Sur Azure, cette fonctionnalité s'appelle l'appairage VNet et, sur Cloud Platform, elle s'appelle l'appairage de réseaux VPC. L'appairage de réseaux virtuels présente plusieurs avantages par rapport aux adresses IP externes ou aux VPN, dont :

  • Latence inférieure à celle des réseaux IP publics.
  • Sécurité accrue : les propriétaires de service peuvent éviter d'exposer leurs services à l'Internet public, et échappent ainsi aux risques associés.

L'appairage VNet d'Azure peut être comparé à l'appairage de réseau VPC de Cloud Platform comme suit :

Fonctionnalité Azure Cloud Platform
Restrictions de localité Les réseaux appairés doivent être dans la même région Aucune restriction ne s'applique.
Services disponibles VM, Cloud Services Compute Engine, environnement flexible App Engine
Nombre maximal de réseaux appairés par réseau Jusqu'à 10 par défaut, avec un maximum de 50 sur demande Jusqu'à 25
Chevauchement d'adresses IP Non compatible Non compatible
Appairage transitif Non compatible Non compatible

Appairage entre unités

Sur Azure, vous pouvez appairer des réseaux virtuels existant dans différents abonnements. De même, sur Cloud Platform, vous pouvez appairer des réseaux VPC existant dans différents projets ou organisations. Pour appairer des réseaux VPC entre des projets, vous pouvez appairer un réseau VPC donné à un réseau VPC partagé. Pour appairer des réseaux VPC entre des organisations, vous pouvez appairer des réseaux VPC existant dans des projets au sein de ces organisations.

Interconnexion dédiée

Dans certains cas, un VPN sur site ou dans le cloud peut ne pas répondre aux besoins en vitesse ou en sécurité d'une charge de travail particulière. Dans ces situations, Azure et Google, en collaboration avec leurs partenaires, vous permettent de louer une ligne réseau dont le niveau de capacité est garanti.

Appairage opérateur

Azure propose ExpressRoute, qui vous permet de configurer une ligne privée louée dans Azure via un site opérateur partenaire. Chaque emplacement du partenaire dessert une région spécifique.

Google propose un service équivalent appelé Cloud Interconnect. Comme avec ExpressRoute et Azure, Cloud Interconnect vous permet de configurer une ligne régionale louée dans Cloud Platform via une infrastructure partenaire. Cependant, la ligne utilise des réseaux publics.

Appairage direct

En plus de l'appairage opérateur, Cloud Platform vous permet également de vous connecter directement au réseau Google plutôt que via un partenaire tiers. Azure n'offre pas ce service.

Appairage de réseau de diffusion de contenu (CDN)

L'appairage de réseau de diffusion de contenu (CDN) fournit une connexion entre vos ressources dans le cloud et un fournisseur CDN via des emplacements de réseaux périphériques. Google offre l'appairage CDN à plusieurs fournisseurs CDN via son service CDN Interconnect.

Azure ne propose pas l'appairage CDN en tant que service. Toutefois, Azure dispose de connexions dédiées aux CDN Akamai et Verizon dans le cadre de son service Azure CDN.

Coûts

Les services VPN d'Azure et de Cloud Platform sont facturés à l'heure.

Pour Cloud Interconnect, le coût de l'appairage opérateur est fixé par le partenaire louant la ligne. Pour ExpressRoute, Azure propose deux modèles de facturation :

  • Données illimitées, pour lesquelles vous payez des frais mensuels pour un transfert de données illimité.
  • Données mesurées, pour lesquelles vous payez des frais mensuels moindres, mais ces données sont également soumises à une facturation par Go de trafic réseau sortant.

Cloud Platform ne facture pas l'appairage direct.

Comme pour l'appairage opérateur, les coûts d'appairage CDN de Cloud Platform sont fixés par le partenaire d'appairage. Cloud Platform ne facture pas l'appairage CDN Interconnect.

Et ensuite ?

Étape suivante : Stockage