Après un premier article sur la découverte des bases de Google Cloud et la création de notre compte, je vous invite maintenant à explorer la partie réseau.
Google Cloud bénéficie du réseau mondial utilisé par les autres services de Google, cela permet de construire notre propre infrastructure distribuée géographiquement. Afin de bien comprendre, nous allons séparer la vue globale de la vue régionale.
Plusieurs régions constituent l’infrastructure de Google Cloud, 15 à l’heure où ces lignes sont écrites et 19 d’ici fin 2018. Les régions sont interconnectées par un réseau privé et performant. Le détail du réseau de Google Cloud est visible sur la page dédiée de la documentation.
Durant le mois d'août 2017, Google a annoncé la séparation de la gestion du réseau entre deux offres : Premium et Standard. L’une utilise l’infrastructure globale du réseau Google Cloud pour relier utilisateurs et régions, l’autre utilise Internet pour atteindre la région de destination.
Le service est encore en Alpha, mais il est intéressant de commencer à réfléchir dès aujourd’hui à nos choix sur cet aspect. Sauf cas particulier, je conseillerais d’utiliser la solution Premium. Des premiers tests de performances ont été réalisés afin de vous donner une idée et d’aiguiller votre décision : GCP Networking Performance.
Chaque région est composée de plusieurs zones correspondant à autant de datacenters distincts. La zone constitue la plus petite unité de disponibilité, cela signifie qui si l’on souhaite déployer en haute disponibilité, il est nécessaire de construire son infrastructure sur au moins deux zones. C’est justement ce que nous nous efforcerons de faire tout au long de nos déploiements !
Les régions permettent de déployer les services à proximité des utilisateurs, et garantissent une faible latence entre les zones.
Chaque zone offre des fonctionnalités qui lui sont propres et qu’il faut prendre en compte au moment du déploiement. Par exemple la région europe-west1-b permet d’ajouter des GPUs sur les serveurs alors que la zone soeur europe-west1-c ne le permet pas.
Pour plus de détails quant aux régions et aux services par zone la documentation dédiée est très complète.
La plateforme offre de nombreux services réseaux, l’idée ici n’est pas de tous les lister et de les expliciter mais plutôt de présenter un échantillon des plus importants pour construire notre infrastructure de base. Si vous voulez un focus supplémentaire sur certains services, n’hésitez pas à le demander dans les commentaires ou via twitter.
Lorsque votre projet a été créé, un réseau virtuel (ou VPC) a été provisionné par défaut. La particularité des réseaux sur GCP est la possibilité de créer un réseau global mondial et d’avoir des sous-réseaux dans chaque région. Ainsi, tous les serveurs déployés au sein d’une région disposent d’adresses IP dans le même sous-réseau, quelle que soit la zone de déploiement. La politique de routage du réseau global permet à tous les serveurs de communiquer directement entre eux à travers le monde, sans restrictions.
Deux modes existent pour la création de VPC :
A vous de jouer maintenant sur la console GCloud pour créer vos propres réseaux. Il n’y a pas de facturation associée à la création de réseaux donc n’hésitez pas à tester et à créer plusieurs réseaux.
Par défaut, nos services déployés n’ont que des adresses IP privées et ne sont donc pas accessibles de l'extérieur. Il est donc important de leur affecter des adresses IP externes pour qu’ils soient joignables depuis internet. Ces IP externes sont de deux types : éphémères ou statiques.
Les adresses éphémères sont par définition volatiles, elles sont prévues pour fournir un accès temporaire et où l’adresse elle-même n’a pas d’importance. Ce genre d’usage est typiquement adapté dans le cas de tests, ou lorsque nos services sont cachés derrière un répartiteur de charge. Notre premier article montrait la création d’un serveur virtuel utilisant justement une adresse éphémère.
Les adresses statiques sont quant à elles prévues pour durer dans le temps, on les utilise typiquement comme destination de serveurs VPN, ou comme cibles des répartiteurs de charge. Elles sont soit régionales, soit globales, en fonction de vos besoins.
Vous pouvez gérer les adresses statiques dans la console. Attention une adresse non utilisée est facturée.
La sécurité réseau des projets est gérée au niveau des règles de pare-feu du réseau VPC entier. Quelques règles par défaut sont proposées, mais il est possible (et même conseillé) d’écrire ses propres règles.
Les règles sont définies pour être mises en œuvre suivant les filtres appliqués au trafic. Il est possible de choisir de les filtrer suivant :
Bien entendu, les sources et cibles peuvent être mixées suivant ces 3 possibilités. Enfin, une notion de priorité s’applique pour hiérarchiser l’ordre d’utilisation des règles.
Essayez de vous connecter à la section pare-feu de la console, et d’ajouter une règle autorisant le trafic HTTP sur les instances ayant le tag “webapp”.
Hint : allow tcp:80 from net:0.0.0.0/0 to tag:webapp
Ensuite il vous suffira de créer une instance et de lui associer le tag webapp pour que le trafic HTTP soit autorisé depuis n’importe où.
Le dernier aspect réseau que j’aimerais aborder avec vous est la répartition de charge (ou load balancing). C’est un aspect complet et complexe d’une architecture cloud, nous allons en parler un peu mais nous l’aborderons plus en détail dans un prochain article.
Lorsque l’on parle de répartition de charge, il nous faut distinguer la charge externe (provenant d’internet) de la charge interne (entre les machines virtuelles), chacune offrant des possibilités différentes que nous allons étudier. Un élément important à noter est que les répartiteurs multi-région vont automatiquement distribuer le trafic des visiteurs vers la région la plus proche d’eux.
Trois types de répartiteurs de charge sont offerts :
N’hésitez pas à aller jouer avec la console, nous créerons un répartiteur de charge lors d’un prochaine article dédié à la performance. Si vous créez un répartiteur, pensez bien à le supprimer après vos tests sinon il vous sera facturé.
La découverte du réseau est terminée, nous allons pouvoir avancer sur les étapes suivantes, restez connectés pour en apprendre plus ! Le code de nos exemples est disponible sur GitHub : https://github.com/bcadiot/gcp-from-scratch.
Vous avez des questions ? Vous voulez plus de détails ? N’hésitez pas dans les commentaires de l’article ou via Twitter.
À très vite pour la suite de notre découverte de Google Cloud. La prochaine étape sera consacrée à la performance et à la haute disponibilité.
A lire et à relire, les articles de la saga "Google Cloud From Scratch".
-Episode 1 : "Commencer par la base"
-Episode 2 : "Parlons Réseau"