Cette section du guide des archétypes de déploiement Google Cloud décrit l'archétype de déploiement zonal.
Dans une architecture cloud qui utilise l'archétype de déploiement zonal de base, l'application s'exécute dans une seule zone Google Cloud, comme illustré dans le schéma suivant :
Pour pouvoir vous remettre des pannes zonales, vous pouvez utiliser une architecture à deux zones dans laquelle une instance répliquée passive de la pile d'applications est provisionnée dans une deuxième zone (de basculement), comme illustré dans le schéma suivant :
Si une panne se produit dans la zone principale, vous pouvez promouvoir la base de données de secours en tant que base de données principale (écriture) et mettre à jour l'équilibreur de charge pour envoyer du trafic vers l'interface dans la zone de basculement.
Cas d'utilisation
Vous trouverez ci-dessous des exemples de cas d'utilisation pour lesquels l'archétype de déploiement zonal est un choix approprié :
- Environnements de développement et de test cloud : vous pouvez utiliser l'archétype de déploiement zonal pour créer un environnement peu coûteux pour le développement et les tests.
- Applications qui n'ont pas besoin de haute disponibilité : l'archétype de déploiement zonal peut être suffisant pour les applications pouvant tolérer des temps d'arrêt.
- Mise en réseau à faible latence entre les composants d'application : une architecture à zone unique peut être adaptée aux applications telles que le calcul par lot qui nécessitent des connexions réseau à faible latence et à bande passante élevée entre les nœuds de calcul.
- Migration de charges de travail standards : l'archétype de déploiement zonal fournit un chemin de migration cloud pour les applications sur site dont vous ne contrôlez pas le code ou qui ne peuvent pas accepter d'architectures autres qu'une topologie active-passive de base.
- Exécuter des logiciels sous licence : l'archétype de déploiement zonal peut être parfaitement adapté aux systèmes sous licence sur lesquels l'exécution de plusieurs instances à la fois est trop coûteuse ou interdite.
Considérations de conception
Lorsque vous créez une architecture basée sur l'archétype de déploiement zonal, tenez compte des temps d'arrêt potentiels en cas de panne zonale ou régionale.
Pannes zonales
Si l'application s'exécute dans une seule zone sans zone de basculement, elle ne peut pas diffuser de requêtes en cas de panne zonale. Pour éviter cette situation, vous devez conserver une instance répliquée passive de la pile d'infrastructure dans une autre zone (de basculement) de la même région. En cas de panne dans la zone principale, vous pouvez promouvoir la base de données de la zone de basculement en tant que base de données principale et vous assurer que le trafic entrant est acheminé vers l'interface dans la zone de basculement. Une fois que Google a résolu la panne, vous pouvez choisir de rebasculer vers la zone principale ou de la définir comme nouvelle zone de basculement.
Pannes régionales
Si une panne régionale se produit, vous devez attendre que Google la résolve, puis vérifier que l'application fonctionne comme prévu. Si vous avez besoin d'une robustesse face aux pannes régionales, envisagez d'utiliser l'archétype de déploiement multirégional.
Architecture de référence
Pour obtenir une architecture de référence permettant de concevoir un déploiement zonal sur des VM Compute Engine, consultez la section Déploiement à zone unique sur Compute Engine.