Google Cloud pour les utilisateurs d'OpenStack

Cet article est conçu pour permettre aux utilisateurs qui connaissent OpenStack de maîtriser les concepts clés pour commencer à utiliser Google Cloud, qu'il s'agisse de migrer ou de mettre en œuvre un déploiement hybride.

Présentation

Cet article compare d'abord des exemples d'architectures d'applications Web à trois niveaux qui sont mis en œuvre dans OpenStack et Google Cloud, puis les fonctionnalités d'OpenStack et de Google Cloud. Il présente des tableaux récapitulatifs mettant en correspondance les termes et concepts associés à OpenStack et ceux propres à Google Cloud.

Cet article ne compare pas les SDK ni les API, ni les outils de ligne de commande fournis par OpenStack et Google Cloud.

Pour obtenir la liste complète des produits Google Cloud, consultez la page Produits et services.

Services de cloud computing

Les services de cloud computing fournissent un ensemble de prestations de base pour le calcul, le stockage, la mise en réseau, la gestion des accès et généralement les bases de données.

Les services de base d'OpenStack incluent les suivants :

  • Pour le calcul, OpenStack Compute (Nova et Glance)
  • Pour le stockage, OpenStack Block Storage (Cinder)
  • Pour la mise en réseau, OpenStack Networking (Neutron)
  • Pour la gestion des identités et des accès, OpenStack Identity (Keystone)

Les services de base de Google Cloud incluent :

Tarifs applicables à Google Cloud

La plupart des services Google Cloud sont proposés sur la base d'un modèle de paiement à l'usage, qui inclut une facturation à la seconde ou à la minute ainsi que des remises automatiques en cas d'utilisation intensive. Combiné à un mécanisme flexible d'allocation des ressources qui s'appuie, entre autres, sur les types de machines personnalisés, le modèle de tarification Google Cloud permet d'optimiser les performances économiques de vos applications.

Pour accéder à des informations et des outils permettant d'estimer rapidement les prix, consultez la page sur le simulateur de coût Google Cloud.

Pourquoi choisir Google Cloud ?

Depuis 15 ans, nous proposons l'une des meilleures infrastructures cloud au monde en termes de rapidité, de puissance et de qualité. Nous utilisons cette infrastructure en interne pour proposer à l'échelle mondiale des services à trafic élevé, tels que Gmail, Maps, YouTube et la recherche Google. Google Cloud met cette infrastructure à votre disposition.

Comparer des exemples d'architectures

Cette section compare les méthodes permettant de créer une application Web à trois niveaux dans OpenStack et dans Google Cloud.

  • L'architecture OpenStack génère une configuration en mode "actif/sauvegarde".
  • L'architecture Google Cloud exploite les services gérés pour fournir une configuration en mode "actif/actif".

Une application Web à trois niveaux standard inclut les éléments suivants :

  • Équilibreur de charge
  • Serveur Web
  • Serveur d'application
  • Serveur de base de données

OpenStack : configuration en mode "actif/sauvegarde"

L'exemple de configuration OpenStack illustré par la figure 1 présente les caractéristiques suivantes :

  • Vous déployez des ressources dans deux régions sous la forme de deux domaines de défaillance distincts pour la redondance.
  • Le réseau utilise un seul sous-réseau pour tous les niveaux de chaque région, et tous les serveurs correspondent à des instances de machine virtuelle (VM).
  • Vous définissez des groupes de sécurité pour les quatre rôles de serveur et les attribuez aux instances appropriées.
  • Un volume Cinder est associé au serveur de base de données en tant que volume de données. Pour assurer la redondance entre les domaines de défaillance, la base de données de la région active est sauvegardée dans un espace de stockage d'objets et restaurée sur la base de données de la région de sauvegarde si nécessaire. (Cette architecture n'utilise pas la réplication de base de données en temps réel, car la bande passante est limitée entre les régions.)
  • Cette architecture fournit une configuration en mode "actif/sauvegarde". Lorsque vous basculez le service vers une autre région, vous restaurez la sauvegarde la plus récente sur le serveur de base de données de la région de sauvegarde.

Application Web à trois niveaux

Figure 1 : Application Web à trois niveaux dans OpenStack

Google Cloud : configuration en mode "actif/actif"

L'exemple de configuration Google Cloud illustré à la figure 2 présente les caractéristiques suivantes :

  • Vous déployez des ressources dans un sous-réseau unique couvrant plusieurs zones d'une même région pour la redondance.
  • Vous déployez des serveurs Web et des serveurs d'applications en tant qu'instances de VM.
  • Vous définissez des règles de pare-feu à l'aide de tags pour spécifier la destination des paquets.
  • Vous définissez le contrôle des accès pour la connexion à la base de données en fonction de l'adresse IP source, dans le cadre de la configuration Cloud SQL. Cloud SQL est un service géré de Google Cloud pour les bases de données MySQL, qui permet la réplication de données entre plusieurs zones. Les processus de sauvegarde de données et de basculement sont automatisés, et vous pouvez accéder à la base de données à partir de plusieurs zones de la même région. Le basculement entre les zones est transparent pour les applications exécutées sur les instances de VM. Vous pouvez accéder à une instance Cloud SQL unique à partir de plusieurs zones. (Il existe deux générations Cloud SQL : Cloud SQL de première génération et Cloud SQL de deuxième génération. Leurs caractéristiques et comportements par défaut pour la réplication et le basculement sont différents.)
  • Google Cloud Load Balancing est un service d'équilibrage de charge HTTP(S) avec lequel on peut utiliser une adresse IP unique globale (VIP) pour distribuer l'accès client entre plusieurs régions et zones.
  • L'architecture fournit une configuration en mode actif/actif pour plusieurs zones, ce qui crée un service redondant pour les domaines de défaillance.

Application Web à trois niveaux

Figure 2 : Application Web à trois niveaux dans Google Cloud

Comparer les fonctionnalités

Cette section compare les caractéristiques des fonctionnalités utilisées dans les exemples d'architectures.

Architecture de réseau

Cette section compare le mode de fonctionnement des réseaux OpenStack et Google Cloud dans les régions et les zones. Elle traite des projets et des locataires, des adresses IP et du processus de basculement, ainsi que des règles de pare-feu.

Régions et zones

Voici comment les termes et concepts d'OpenStack sont mis en correspondance avec ceux de Google Cloud :

OpenStack Google Cloud Notes
Région Région Dans OpenStack, une région peut couvrir plusieurs centres de données. Dans Google Cloud, une région correspond à un site de centre de données comportant généralement plusieurs bâtiments indépendants.
Zone de disponibilité Zone Dans OpenStack, une zone de disponibilité sert généralement à identifier un ensemble de serveurs ayant un attribut commun.

Dans Google Cloud, une zone correspond à un cluster d'un centre de données.

Dans OpenStack, une région est définie comme un cluster unique géré par des nœuds de contrôleurs dédiés. Elle est composée de zones de disponibilité. Vous pouvez utiliser les zones de disponibilité pour définir plusieurs groupes de ressources tels que des nœuds de calcul et des unités de stockage.

Dans Google Cloud, une région correspond à un espace géographique indépendant qui est constitué de zones. Les zones des régions présentent généralement des latences réseau aller-retour inférieures à 5 ms au 95e centile. Comme les zones de disponibilité OpenStack, elles sont utilisées pour le déploiement des ressources Google Cloud au sein d'une région. Chaque zone doit être considérée comme un domaine de défaillance unique.

Google Cloud fournit un réseau interne dédié pour toutes les régions, de sorte que la bande passante et la latence entre les différentes zones d'une même région soient comparables à celles garanties au sein de la région. Vous pouvez déployer une application de cluster à couplage étroit dans plusieurs zones sans vous soucier de la bande passante et de la latence entre les zones.

Sur les deux plates-formes, le déploiement de l'application dans plusieurs zones ou régions offre une meilleure protection contre les défaillances inattendues. Dans Google Cloud, les zones sont considérées comme des domaines de défaillance indépendants. En revanche, dans OpenStack, ce sont les régions (et non les zones de disponibilité) qui sont considérées comme des domaines de défaillance indépendants, car les zones de disponibilité d'une même région partagent les mêmes nœuds de contrôleurs. Pour obtenir la liste des zones et régions Google Cloud, consultez la page Emplacements Cloud.

Projets et locataires

Voici comment les termes et concepts d'OpenStack sont mis en correspondance avec ceux de Google Cloud :

OpenStack Google Cloud Notes
Locataire Projet Toutes les ressources Google Cloud doivent appartenir à un projet. Les utilisateurs peuvent créer leurs propres projets.

Dans OpenStack, seuls les administrateurs peuvent créer des locataires.

Vous devez configurer un compte Google pour utiliser les services Google Cloud. L'utilisation des services est regroupée par projet dans Google Cloud. Vous pouvez créer plusieurs projets totalement distincts au sein d'un même compte. Par ailleurs, vos utilisateurs ont la possibilité de créer leurs propres projets avec leur compte. Les ressources d'un même projet peuvent facilement travailler de concert (par exemple, en communiquant via un réseau interne conformément aux règles applicables aux régions et aux zones). Les ressources d'un projet donné sont isolées de celles des autres projets. Vous ne pouvez les interconnecter que via une connexion réseau externe.

Ce modèle vous permet de créer des espaces de projet pour des départements ou des groupes distincts au sein de votre entreprise. Il peut également s'avérer utile pour réaliser des tests : en effet, lorsque vous avez fini de travailler sur un projet, vous pouvez le supprimer. Toutes les ressources associées à ce dernier sont alors également supprimées.

OpenStack utilise le terme locataire pour désigner une fonctionnalité similaire permettant d'isoler les ressources de différents groupes. Dans OpenStack, seuls les administrateurs système peuvent créer des locataires.

Configurations réseau

Voici comment les termes et concepts d'OpenStack sont mis en correspondance avec ceux de Google Cloud :

OpenStack Google Cloud Notes
Neutron Cloud Virtual Network Cloud Virtual Network est un service de réseau géré. Dans Google Cloud, vous pouvez définir plusieurs réseaux au sein de votre projet. Chaque réseau est indépendant.
Réseau privé virtuel
Réseau privé virtuel Un seul réseau privé virtuel Google Cloud couvre toutes les régions connectées via le réseau interne de Google Cloud. Un réseau privé virtuel Neutron englobe toutes les zones de disponibilité d'une région.

Dans un déploiement OpenStack Neutron standard, le réseau virtuel de chaque locataire est contenu dans son propre espace réseau privé. Comme le montre la figure 1, vous ne devez pas nécessairement utiliser plusieurs sous-réseaux, mais vous pouvez en configurer plusieurs en cas de besoin. La figure 3 représente un réseau virtuel OpenStack composé d'un seul routeur virtuel et de trois commutateurs virtuels. Deux des commutateurs virtuels se connectent au réseau externe via le routeur virtuel. AZ-1 et AZ-2 correspondent aux zones de disponibilité.

réseau virtuel

Figure 3 : Exemple de configuration d'un réseau OpenStack

Google Cloud propose deux types de réseaux : les anciens réseaux et les sous-réseaux.

Les anciens réseaux fournissent un seul sous-réseau privé qui couvre toutes les régions du monde, comme illustré par la figure 4.

Dans un réseau de sous-réseaux (illustré par la figure 5), le commutateur virtuel correspond à un routeur virtuel OpenStack Neutron. Les commutateurs virtuels sont connectés via le réseau interne. Tous les sous-réseaux peuvent être redirigés les uns vers les autres via des adresses IP privées. Vous n'êtes donc pas obligé d'utiliser des adresses IP globales ou Internet pour permettre la communication entre les régions.

Dans Google Cloud, vous pouvez utiliser à la fois des anciens réseaux et des réseaux de sous-réseaux d'un projet. Chaque nouveau projet comprend un réseau prédéfini par défaut, qui inclut lui-même un sous-réseau par défaut dans chaque région.

ancien réseau

Figure 4 : Exemple de configuration d'un ancien réseau Google Cloud

réseau de sous-réseaux

Figure 5 : Exemple de configuration d'un réseau de sous-réseaux Google Cloud

Adresses IP

Voici comment les termes et concepts d'OpenStack sont mis en correspondance avec ceux de Google Cloud :

OpenStack Google Cloud
Les instances disposent d'adresses IP internes privées. Une adresse IP globale (flottante) peut être attribuée si nécessaire.

Les instances disposent d'adresses IP internes privées. En outre, lorsqu'une instance est créée à l'aide de l'outil de ligne de commande "gcloud", une adresse IP éphémère est automatiquement attribuée. Des adresses IP statiques peuvent également être allouées si nécessaire.
Des adresses IP globales sont requises pour la communication entre des instances situées dans différentes régions ou associées à des routeurs virtuels distincts. Les sous-réseaux de toutes les régions peuvent être redirigés les uns vers les autres via des adresses IP privées. Vous n'êtes donc pas obligé d'utiliser des adresses IP globales ou Internet pour permettre la communication entre les instances.

Dans Neutron, les instances de VM d'un réseau privé communiquent via des commutateurs et des routeurs virtuels à l'aide d'adresses IP privées qui sont attribuées lors du lancement. Les adresses IP globales ne sont pas attribuées par défaut.

Le routeur virtuel gère l'accès des instances de VM au réseau externe, de sorte que ces dernières partagent l'adresse IP globale commune qui leur est attribuée. Pour exposer une instance au réseau externe et autoriser les connexions d'utilisateurs externes, vous devez attribuer une adresse IP flottante à l'instance à partir d'un pool d'adresses IP globales.

Le réseau virtuel étant contenu dans une seule région, les instances de différentes régions doivent utiliser les adresses IP flottantes pour communiquer via le réseau externe.

Un même réseau peut inclure plusieurs routeurs virtuels. Les instances de VM connectées aux différents routeurs ne peuvent pas communiquer directement via des adresses IP privées. Toutefois, elles communiquent via le réseau externe à l'aide d'adresses IP flottantes.

Dans Google Cloud, toutes les instances de VM disposent d'une adresse IP interne et d'une adresse IP externe lors de leur lancement. Vous pouvez dissocier une adresse IP externe si nécessaire.

Par défaut, une adresse IP externe est éphémère, ce qui signifie qu'elle n'existe que pendant la durée de vie de l'instance. Si vous arrêtez, puis redémarrez une instance, une autre adresse IP externe peut lui être attribuée. Vous pouvez également demander une adresse IP permanente, appelée adresse IP statique, afin de l'associer à une instance. Cette adresse vous appartient jusqu'à ce que vous décidiez de la libérer. Vous devez l'attribuer de façon explicite à des instances de VM. Les adresses IP statiques peuvent être associées aux instances et dissociées de ces dernières selon les besoins.

Comme illustré dans les exemples d'architectures d'applications Web à trois niveaux, en cas de basculement, OpenStack ne permet pas d'utiliser la même adresse IP globale dans différentes régions. Vous devez donc faire appel à un autre mécanisme, tel que le DNS dynamique, pour permettre aux clients de continuer à accéder au service au moyen de la même URL.

En revanche, dans Google Cloud, vous pouvez utiliser une seule adresse IP globale (virtuelle) fournie par Cloud Load Balancing pour distribuer l'accès client entre plusieurs régions et zones. De cette façon, un basculement s'effectue entre les régions et les zones de manière transparente pour les clients.

Pare-feu

Voici comment les termes et concepts d'OpenStack sont mis en correspondance avec ceux de Google Cloud :

OpenStack Google Cloud Notes
Applique les règles de pare-feu au moyen de groupes de sécurité. Applique les règles de pare-feu au moyen de règles et de tags. Un groupe de sécurité OpenStack contient plusieurs listes de contrôle d'accès (LCA) que vous définissez en fonction du rôle de l'instance, puis que vous attribuez à cette dernière.

Les groupes de sécurité OpenStack doivent être définis pour chaque région.

Les règles et tags Google Cloud peuvent être définis une seule fois, et utilisés dans toutes les régions.

Dans OpenStack, un même groupe de sécurité contient plusieurs listes de contrôle d'accès (LCA) indépendantes des instances de VM. Vous devez attribuer un groupe de sécurité à une instance de VM pour lui appliquer les LCA. Les groupes de sécurité sont généralement définis en fonction des rôles des instances de VM (serveur Web ou serveur de base de données, par exemple).

Ainsi, pour l'exemple d'architecture, vous devez définir les groupes de sécurité ci-dessous pour chaque région.

Groupe de sécurité Source Protocole
load-balancer toutes HTTP/HTTPS
Sous-réseau de gestion SSH
web-server load-balancer HTTPS
Sous-réseau de gestion SSH
web-application web-server TCP 8080
Sous-réseau de gestion SSH
database web-application MYSQL
Sous-réseau de gestion SSH

Vous pouvez spécifier la source des paquets avec une plage de sous-réseaux ou le nom d'un groupe de sécurité. Dans le tableau précédent, le sous-réseau de gestion désigne une plage de sous-réseaux à partir de laquelle les administrateurs système se connectent au système d'exploitation invité à des fins de maintenance.

Cette architecture suppose que le client SSL se termine au niveau de l'équilibreur de charge qui communique avec les serveurs Web via le protocole HTTPS. Ces derniers communiquent avec les serveurs d'applications via le port TCP 8080. Le protocole MySQL est utilisé pour le serveur de base de données.

Après avoir défini ces groupes de sécurité, vous devez les attribuer à chaque instance comme indiqué ci-dessous.

Instance Groupe de sécurité
Équilibreur de charge load-balancer
Serveur Web web-server
Serveur d'application web-application
Serveur de base de données database

Le service Cloud Virtual Network de Google Cloud vous permet de définir des règles de pare-feu qui s'appliquent à toutes les régions en combinant des règles et des tags. Un tag correspond à un libellé arbitraire qui est associé à une instance de VM. Vous pouvez attribuer plusieurs tags à une même instance. Une règle est une LCA qui permet à un paquet de circuler selon les conditions ci-dessous :

  • Source : plage d'adresses IP, sous-réseau, tags
  • Destination : tags

Par exemple, vous pouvez tout d'abord définir une règle qui autorise l'envoi de paquets utilisant le port de destination TCP 80 depuis toute adresse IP vers le tag web-server. Vous avez ensuite la possibilité d'ajouter le tag "web-server" à n'importe quelle instance de VM pour autoriser les connexions HTTP vers celle-ci. Vous devez gérer séparément les tags servant à indiquer les rôles des instances et les règles permettant de spécifier les LCA correspondant aux rôles.

La figure 6 présente certaines règles prédéfinies pour le réseau par défaut dans un nouveau projet. Par exemple, 10.128.0.0/9 est une plage de sous-réseaux qui contient les sous-réseaux sous-jacents de toutes les régions. Cette plage peut varier selon les projets. Du début à la fin du projet, les règles autorisent les connexions réseau suivantes :

  • Paquets ICMP (Internet Control Message Protocol) provenant de n'importe quelle source externe
  • Paquets échangés entre toutes les instances qui sont connectées au réseau par défaut
  • Connexion RDP (Remote Desktop Protocol) à partir de n'importe quelle source externe
  • Connexion SSH (Secure Shell) à partir de n'importe quelle source externe

Règles de pare-feu prédéfinies

Figure 6 : Règles de pare-feu prédéfinies dans Cloud Virtual Network pour le réseau par défaut

Pour en savoir plus, consultez Utiliser des réseaux et des pare-feu.

Dans les règles de pare-feu Google Cloud, vous devez utiliser d'une part des tags pour spécifier la destination des paquets et, d'autre part, des plages de sous-réseaux ou des tags pour indiquer la source des paquets. Dans ce scénario, vous définissez les règles suivantes :

Source Destination Protocole
130.211.0.0/22 web-server HTTP, HTTPS
web-server web-application TCP 8080
Sous-réseau de gestion web-server, web-application SSH

Dans le tableau précédent, 130.211.0.0/22 correspond à la plage de sous-réseaux à partir de laquelle l'équilibreur de charge et le système de vérification de l'état accèdent au serveur Web. Le sous-réseau de gestion désigne une plage de sous-réseaux à partir de laquelle les administrateurs système se connectent au système d'exploitation invité à des fins de maintenance. web-server et web-application sont les tags attribués respectivement au serveur Web et au serveur d'application. Au lieu d'attribuer des règles comme si vous utilisiez des groupes de sécurité, vous allouez des tags aux instances en fonction de leur rôle.

Le contrôle des accès pour la connexion à la base de données est défini en fonction de l'adresse IP source dans le cadre de la configuration de Cloud SQL.

Stockage

Voici comment les termes et concepts d'OpenStack sont mis en correspondance avec ceux de Google Cloud :

OpenStack Google Cloud Notes
Volumes Cinder Disques persistants Espace de stockage persistant qui est associé à une instance

Avec les disques persistants Google Cloud, les données sont automatiquement chiffrées avant leur transfert de l'instance vers le disque persistant.

Espaces disques éphémères ND Espace de stockage éphémère qui est associé à une instance
OpenStack Swift Cloud Storage Services de stockage d'objets
Espaces disques éphémères et volumes Cinder

OpenStack propose deux options pour les disques associés à une instance : les espaces disques éphémères et les volumes Cinder.

Les espaces disques éphémères sont conçus pour être utilisés en tant que disques système contenant les fichiers du système d'exploitation, alors que les volumes Cinder sont destinés à stocker des données d'application persistantes. Les espaces disques éphémères ne permettant pas la migration à chaud, il est fréquent que les utilisateurs emploient les volumes Cinder également en tant que disques système.

Lorsqu'un espace disque éphémère est utilisé en tant que disque système, une image du modèle de système d'exploitation est copiée dans l'espace de stockage local d'un nœud de calcul, et l'image locale est associée à l'instance. Lorsque l'instance est détruite, l'image associée l'est également.

Les volumes Cinder fournissent un espace disque persistant qui réside dans des périphériques de stockage externes. Dans les déploiements standards, le périphérique en mode bloc est associé au nœud de calcul à l'aide du protocole iSCSI. Il est par ailleurs associé à l'instance en tant que disque virtuel. Lorsque l'instance est détruite, le volume associé reste dans le périphérique externe et peut être réutilisé à partir d'une autre instance.

Le logiciel d'application exécuté sur l'instance peut également accéder à l'espace de stockage d'objets fourni par OpenStack Swift.

espace disque éphémère et volume Cinder

Figure 7 : Comparaison entre les espaces disques éphémères et les volumes Cinder utilisés dans OpenStack

Disques persistants

Google Cloud fournit un espace de stockage persistant qui est associé à une instance sous la forme de disques persistants. Ceux-ci sont semblables aux volumes Cinder d'OpenStack. Vous pouvez utiliser un disque persistant en tant que disque système contenant les fichiers du système d'exploitation ainsi que pour stocker des données d'application persistantes. Les données sont automatiquement chiffrées avant leur transfert de l'instance vers le disque persistant. Vous pouvez augmenter la capacité d'un même disque persistant jusqu'à 64 To. Toutefois, la capacité totale maximale des disques associés est limitée par la taille de l'instance. Pour en savoir plus, consultez Options de stockage.

Si vous avez besoin d'une solution de stockage locale hautes performances, vous pouvez également utiliser des disques persistants SSD locaux. La taille de chacun de ces disques est de 375 Go. Il est toutefois possible d'associer jusqu'à huit disques SSD locaux par instance pour obtenir au total un espace de stockage SSD local de 3 To. Notez que la migration à chaud est disponible pour les instances associées à des disques SSD locaux. Étant donné que les données de ces disques sont copiées d'une instance à une autre lors de la migration à chaud, les performances de stockage peuvent diminuer temporairement.

Le logiciel d'application exécuté sur l'instance peut accéder à l'espace de stockage d'objets fourni par Cloud Storage, un service hébergé permettant de stocker un grand nombre d'objets binaires (ou blobs) de taille variable et d'y accéder.

Instances de VM

Voici comment les termes et concepts d'OpenStack sont mis en correspondance avec ceux de Google Cloud :

OpenStack Google Cloud Notes
Type d'instance Type de machine Dans OpenStack, les utilisateurs standards ne peuvent pas créer de type d'instance personnalisé.

Dans Google Cloud, tout utilisateur peut créer des types de machines personnalisés.
Service de métadonnées Serveur de métadonnées OpenStack ne fournit des informations que sur les instances.

Google Cloud fournit également des informations sur les projets.

Lorsque vous lancez une nouvelle instance de VM dans OpenStack, vous choisissez un type d'instance pour spécifier la taille de l'instance, telle que le nombre de processeurs virtuels et la quantité de mémoire. Si l'administrateur système vous a attribué des droits d'accès appropriés, vous pouvez définir d'autres types d'instances. Les utilisateurs standards ne sont pas autorisés à ajouter des types d'instances personnalisés.

Dans Google Cloud, les tailles des instances sont définies sous la forme de types de machines. Les utilisateurs peuvent non seulement choisir l'un des types de machines prédéfinis, mais également spécifier séparément le nombre de processeurs virtuels et la quantité de mémoire pour créer un type de machine personnalisé. Pour en savoir plus, consultez la page Types de machines.

Métadonnées

OpenStack fournit un service de métadonnées permettant de récupérer les informations relatives aux instances de VM (telles que le type d'instance, les groupes de sécurité et les adresses IP attribuées) à partir du système d'exploitation invité des instances. Vous pouvez également ajouter des métadonnées personnalisées sous forme de paires valeur/clé. OpenStack fournit un type de métadonnées nommé user-data. Lorsque vous lancez une nouvelle instance, vous pouvez spécifier un fichier texte exécutable de type user-data afin que l'agent cloud-init qui s'exécute dans le système d'exploitation invité effectue les tâches de configuration au démarrage en fonction du contenu, par exemple, l'installation de packages d'application. Vous utilisez l'URL sous http://169.254.169.254/latest/meta-data pour accéder aux métadonnées du système d'exploitation invité.

Google Cloud fournit un serveur de métadonnées pour récupérer les informations sur les instances et les projets à partir du système d'exploitation invité des instances. Les métadonnées d'un projet sont partagées par toutes les instances qui lui sont associées. Vous pouvez ajouter des métadonnées personnalisées pour une instance et pour un projet sous forme de paires valeur/clé. Google Cloud fournit des métadonnées spéciales appelées startup-script et shutdown-script, qui sont exécutées respectivement lorsque vous démarrez ou arrêtez l'instance.

Contrairement au script user-data d'OpenStack, le script startup-script est exécuté à chaque redémarrage de l'instance. Les scripts startup-script et shutdown-script sont tous deux gérés par l'agent inclus dans le package d'agents compute-image-packages, qui est préinstallé dans les images du modèle du système d'exploitation. Pour en savoir plus, consultez la section Stocker et récupérer les métadonnées d'instances.

Vous devez utiliser l'une des URL suivantes pour accéder aux métadonnées à partir du système d'exploitation invité :

  • http://metadata.google.internal/computeMetadata/v1/
  • http://metadata/computeMetadata/v1/
  • http://169.254.169.254/computeMetadata/v1/
Agent du système d'exploitation invité
OpenStack Google Cloud Notes
Package d'agents de tâches de configuration cloud-init Package d'agents de tâches de configuration compute-image-packages L'agent OpenStack ne gère que les paramètres de démarrage initiaux.

L'agent Google Cloud gère les paramètres de démarrage initiaux et les modifications de configuration dynamiques pendant l'exécution de l'instance.

Dans OpenStack, le package d'agents cloud-init est préinstallé dans les images standards du système d'exploitation invité. Il gère les tâches de configuration initiales lors du premier démarrage (extension de l'espace du système de fichiers racine, stockage d'une clé publique SSH et exécution du script "user-data" fourni en tant que données utilisateur, par exemple).

Dans Google Cloud, le package d'agents compute-image-packages est préinstallé dans les images standards du système d'exploitation invité. Il gère les tâches de configuration initiales via le startup-scriptlors du premier démarrage, ainsi que la configuration système dynamique pendant l'exécution du système d'exploitation invité (en ajoutant des clés publiques SSH et en modifiant les configurations réseau pour l'équilibrage de charge HTTP, par exemple). Après avoir lancé une instance, vous pouvez générer et ajouter une clé SSH via Google Cloud Console ou l'outil de ligne de commande gcloud.

Dans Google Cloud, le SDK Cloud est préinstallé dans les images standards du système d'exploitation invité. Vous pouvez l'utiliser pour accéder aux services Google Cloud à partir du système d'exploitation invité à l'aide d'un compte de service disposant de certains privilèges par défaut.

Contrôle des accès

Dans Google Cloud, IAM applique un contrôle des accès par instance. Par exemple, si vous souhaitez que votre application exécutée sur une instance stocke des données dans Google Cloud Storage, vous pouvez attribuer une autorisation en lecture/écriture à l'instance. Avec IAM, vous n'avez pas à préparer manuellement les mots de passe ni les codes d'identification pour les applications s'exécutant sur l'instance. Pour en savoir plus, consultez la page Créer et activer des comptes de service pour les instances.

Le service Keystone d'OpenStack offre un contrôle des accès basé sur les comptes utilisateur pour les API de service. En revanche, il ne fournit pas de contrôle des accès basé sur les instances (tel que les autorisations en lecture/écriture qui s'appliquent au stockage des objets ou aux bases de données) pour les API d'application. Vous pouvez mettre en œuvre un contrôle des accès personnalisé pour les API d'application si nécessaire.

Au-delà des solutions IaaS : les offres Platform as a Service

Cet article compare les composants et les services proposés par OpenStack et Google Cloud qui sont essentiels pour les déploiements IaaS. Cependant, pour tirer le meilleur parti de Google Cloud en termes de disponibilité, d'évolutivité et d'efficacité opérationnelle, vous devez combiner les services gérés pour qu'ils constituent la base de l'ensemble du système.

La gamme complète de services Google Cloud s'étend bien au-delà du concept traditionnel de plate-forme IaaS et comprend, entre autres, les éléments suivants :

Étapes suivantes

  • Découvrez comment intégrer Dataproc aux services de stockage, de calcul et de surveillance de Google Cloud pour créer une plate-forme complète de traitement des données.
  • Obtenez plus d'informations sur les fonctionnalités de surveillance, de journalisation et de diagnostic offertes par Google Stackdriver.
  • Familiarisez-vous avec BigQuery, un entrepôt de données entièrement géré qui est destiné aux analyses de données. Il fournit une plate-forme sans serveur vous permettant de vous concentrer sur les tâches d'analyse SQL, même avec des ensembles de données à l'échelle du pétaoctet.
  • Apprenez-en plus sur les produits et services Google Cloud.