Modèles d'architecture hybride et multicloud

Cet article constitue la deuxième partie d'une série traitant des déploiements hybrides et multicloud, des modèles d'architecture et des topologies de réseau. Cette partie explore les modèles courants d’architecture hybride et multicloud. Chaque section décrit les scénarios auxquels ces modèles sont les plus adaptés, et présente les pratiques recommandées pour leur mise en œuvre dans Google Cloud Platform (GCP).

La série se compose des parties suivantes :

Chaque entreprise dispose d’un portefeuille unique de charges de travail d’application qui imposent des exigences et des contraintes à l’architecture d’une configuration hybride ou multicloud. Bien que vous deviez concevoir et adapter votre architecture pour répondre à ces contraintes et exigences, vous pouvez aussi vous appuyer sur certains modèles courants.

Les modèles entrent dans deux catégories :

  • Modèles qui reposent sur un déploiement distribué d'applications. Ces modèles ont pour but de lancer une application dans l'environnement informatique qui lui convient le mieux, en misant sur les différentes propriétés et caractéristiques des environnements informatiques.

  • Modèles basés sur des déploiements redondants d'applications. Dans ces modèles, vous déployez les mêmes applications dans plusieurs environnements informatiques pour une capacité ou résilience accrue.

Modèles de déploiement distribué

Lorsque vous migrez d'un environnement informatique classique vers une configuration hybride ou multicloud, tenez compte des contraintes imposées par les applications existantes. Vous devez aussi tirer parti des fonctionnalités uniques offertes par chaque environnement informatique. Ces modèles distribués visent à établir un équilibre judicieux entre ces deux objectifs.

Hybride par tranche

La plupart des applications appartiennent à l'une de deux catégories : applications d'interface ou applications de backend.

  • Les applications d'interface sont directement exposées aux utilisateurs finaux ou aux appareils. Par conséquent, ces applications sont souvent sensibles aux performances et peuvent être soumises à des mises à jour fréquentes à mesure que de nouvelles fonctionnalités et améliorations sont développées. Comme elles reposent généralement sur des applications backend pour stocker et gérer les données, les applications d'interface sont souvent sans état ou ne gèrent que de petits volumes de données.

  • Les applications backend sont généralement dédiées à la gestion des données. Pour ce type d'applications, la gestion des données à grands volumes et leur sécurisation posent des défis clés. Les applications backend ont tendance à être mises à jour moins souvent que les applications d'interface.

Le concept de modèle hybride par tranche consiste à procéder d'abord au déploiement d'applications d'interface existantes dans le cloud public. Dans ce modèle, vous réutilisez des applications backend existantes qui restent dans leur environnement informatique privé. Vous procédez à la migration des applications d'interface au cas par cas.

Le schéma suivant montre un modèle hybride par tranche.

modèle hybride par tranche

Au fil du temps, le nombre d'applications que vous déployez dans le cloud augmente, au point que vous pourriez également envisager de transférer les applications d'interface dans le cloud public.

Avantages

Le fait de se concentrer d'abord sur les applications d'interface présente plusieurs avantages :

  • Les applications d'interface dépendent des backends et parfois d'autres interfaces, mais les backends ne dépendent jamais des interfaces. Par conséquent, l'isolement et la migration d'applications d'interface ont tendance à être moins complexes que la migration d'applications backend, qui peuvent avoir des dépendances complexes.

  • Étant donné que les applications d'interface sont souvent sans état ou qu'elles ne gèrent pas les données elles-mêmes, elles ont tendance à être plus faciles à migrer.

Le déploiement d'applications d'interface existantes ou nouvellement développées sur le cloud public présente plusieurs avantages clés :

  • De nombreuses applications d'interface sont soumises à des modifications fréquentes. Lorsque ces applications sont exécutées dans le cloud public, la configuration d'un processus d'intégration continue / de déploiement continu (CI/CD) que vous pouvez utiliser pour déployer les mises à jour de manière efficace et automatisée s'en voit simplifiée.

  • Les interfaces sensibles aux performances et les interfaces soumises à des modifications fréquentes peuvent grandement bénéficier des fonctionnalités d'équilibrage de charge, de déploiement multirégional et d'autoscaling activées par un déploiement dans le cloud.

  • Qu'elles implémentent des interfaces utilisateur ou des API, ou qu'elles gèrent l'ingestion de données IdO (Internet des objets), les applications d'interface peuvent bénéficier des fonctionnalités des services cloud tels que Firebase, Cloud Content Delivery Network ou Cloud IdO.

Si vos backends gèrent des données soumises à des restrictions réglementaires ou juridictionnelles, vous souhaiterez probablement les conserver dans un environnement informatique privé de manière permanente ou au moins jusqu'à ce que vous trouviez un moyen de respecter les restrictions imposées.

Vous pouvez également appliquer le modèle hybride par tranche dans l'ordre inverse, bien que cela soit moins courant, en déployant des backends dans le cloud tout en conservant les interfaces dans des environnements informatiques privés. Cette approche est particulièrement adaptée à une interface lourde et monolithique. Dans ce cas, il pourrait être plus facile d’extraire les fonctionnalités de backend par itération et de déployer ces nouveaux backends dans le cloud.

Bonnes pratiques

Lorsque vous appliquez le modèle hybride par tranche, tenez compte des pratiques suivantes :

  • Utilisez une topologie de sortie contrôlée ou maillée. Comme la plupart des interactions utilisateur impliquent des systèmes connectés à travers plusieurs environnements informatiques, une connectivité rapide et à faible latence entre ces systèmes est importante. Il est donc crucial de concevoir des systèmes offrant une haute disponibilité, une faible latence et des débits appropriés.

  • Pour minimiser la latence des communications entre les environnements, choisissez une région GCP et un emplacement d'interconnexion géographiquement proches de votre environnement informatique privé.

  • Dans une configuration hybride par tranche, vous avez généralement de plus grands volumes de données entrant dans GCP (entrée) que de volumes sortant de l'environnement GCP en direction de l'environnement informatique privé (sortie). Néanmoins, sachez que le trafic quittant GCP est soumis à des frais de sortie. L’utilisation d’interconnexions dédiées ou d'appairages directs peut vous aider à réduire ces frais.

  • Assurez-vous que la communication entre les environnements est unidirectionnelle. Les applications d'interface exécutées dans le cloud public sont autorisées à communiquer avec les backends exécutés dans des environnements informatiques privés, mais pas l'inverse.

  • Les données échangées entre les environnements pouvant être sensibles, assurez-vous que toutes les communications sont chiffrées en utilisant des tunnels de réseau privé virtuel (VPN), TLS (Transport Layer Security) ou les deux.

  • Nous vous recommandons de déployer une passerelle API en tant que façade pour les services backend existants, en particulier lorsque les protocoles, les API et les mécanismes d'authentification sont incohérents entre les différents backends. En plus de servir de couche d'unification, une passerelle API peut servir de goulot d'étranglement. Avec cette passerelle, vous pouvez implémenter des mesures de sécurité et d'audit supplémentaires qui s'appliquent à toutes les communications entre environnements.

  • Établissez une identité commune entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée au-delà des limites de l'environnement.

Pour les charges de travail individuelles, tenez compte des bonnes pratiques supplémentaires suivantes :

  • Bien que l'accent soit mis sur les applications d'interface dans ce modèle, n'oubliez pas pour autant la nécessité de moderniser les applications backend. Si le rythme de développement des backends est nettement plus lent que celui des interfaces, cette différence peut entraîner une complexité supplémentaire dans les projets.

  • Pour permettre les migrations de type "transformer et déplacer", utilisez Kubernetes en tant que couche d'exécution commune entre GCP et les environnements privés. Avec Kubernetes, vous pouvez moderniser une charge de travail et procéder à la migration vers GCP à différents moments, ce qui peut être crucial lorsqu'une charge de travail dépend fortement d'une autre et ne peut pas être migrée individuellement.

  • Évitez qu'une communication bidirectionnelle soit requise entre les environnements. Pour cela, envisagez également de déployer tout système CI/CD dans le cloud public.

  • Dans un scénario hybride par tranche, utilisez des outils et processus CI/CD cohérents dans tous les environnements pour accroître l'efficacité opérationnelle. Cette pratique n'est pas obligatoire.

  • Lorsque vous utilisez Kubernetes pour exécuter des charges de travail d'interface, utilisez des services sans sélecteur pour rendre détectables tous les services ou passerelles d'API exécutés dans l'environnement informatique privé. En utilisant des domaines Kubernetes simulés, vous pouvez procéder à une intégration avec des systèmes de découverte de services externes basés sur DNS, tels que Consul.

Multicloud partitionné

Le modèle multicloud partitionné associe plusieurs environnements de cloud public, exploités par différents fournisseurs, de manière à vous donner la flexibilité de déployer une application dans un environnement informatique optimal. Le schéma suivant illustre un modèle multicloud partitionné classique.

modèle multicloud partitionné

Vous pouvez conserver la possibilité de déplacer les charges de travail d'un environnement de cloud public à un autre selon les besoins. Dans ce cas, la portabilité des charges de travail devient une exigence clé. Lorsque vous déployez des charges de travail dans plusieurs environnements informatiques et que vous souhaitez conserver la possibilité de les déplacer, vous devez éliminer les différences qui existent entre les environnements.

GCP fournit un ensemble complet de services vous permettant de déployer vos charges de travail de différentes manières. Néanmoins, dans certaines situations, il pourrait être judicieux de combiner GCP avec un autre fournisseur cloud et de partitionner les charges de travail dans différents environnements de cloud. Voici quelques exemples :

  • Pour éviter de vous engager auprès d'un seul fournisseur, répartissez les applications sur plusieurs fournisseurs cloud.

  • Pour des raisons réglementaires, vous fournissez des services à un certain segment de votre base d'utilisateurs et diffusez des données depuis un pays où GCP n'est pas encore présent.

  • Vous déployez des applications auprès de plusieurs fournisseurs cloud, d'une manière qui vous permet de choisir parmi les meilleurs services offerts par les différents fournisseurs.

Avantages

Voici quelques avantages clés du modèle multicloud partitionné :

  • Vous évitez toute dépendance vis-à-vis d'un fournisseur. Ce modèle permet de réduire les risques stratégiques et vous offre la possibilité de modifier votre plan ou votre partenariat ultérieurement.

  • Lorsque vous conservez la portabilité des charges de travail, vous pouvez optimiser vos opérations en déplaçant les charges de travail entre différents environnements informatiques.

Bonnes pratiques

  • Comparez les avantages stratégiques d'une configuration multicloud partitionnée à la complexité supplémentaire qu'elle apporte. Pour parvenir à une portabilité des charges de travail et à une cohérence des outils entre plusieurs environnements de cloud, vous devrez livrer des efforts accrus dans le développement, les tests et les opérations.

  • N'utilisez un environnement multicloud que pour les charges de travail critiques ou si, pour des raisons juridiques ou réglementaires, un environnement de cloud public ne peut pas prendre en charge les charges de travail à lui seul.

  • Minimisez les dépendances entre les systèmes exécutés dans différents environnements de cloud public, en particulier lorsque la communication est gérée de manière synchrone. Ces dépendances peuvent ralentir les performances et réduire la disponibilité globale.

  • Pour éliminer les différences entre les environnements, envisagez d'utiliser des conteneurs et Kubernetes.

  • Assurez-vous que les processus CI/CD et les outils de déploiement et de surveillance sont cohérents sur l'ensemble des environnements de cloud.

  • Utilisez la topologie maillée ou contrôlée.

  • Les données échangées entre différents environnements pouvant être sensibles, assurez-vous que toutes les communications sont chiffrées en utilisant des tunnels VPN, TLS ou les deux.

  • Établissez une identité commune entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée au-delà des limites de l'environnement.

  • Lorsque vous utilisez Kubernetes, envisagez d'utiliser ExternalDNS pour rendre les services identifiables par nom DNS dans les environnements informatiques.

  • Bien que vous puissiez utiliser les équilibreurs de charge Anycast GCP basés sur IP pour équilibrer les requêtes entre plusieurs régions GCP, vous ne pouvez pas les utiliser pour répartir les requêtes d'utilisateurs sur plusieurs clouds. Pour cela, vous devez utiliser l'interrogation à répétition alternée ou Geo DNS, qui sont des services proposés par les fournisseurs de services tels que NS1, Dyn ou Akamai.

Analytique hybride/multicloud

Dans les systèmes d'entreprise, la plupart des charges de travail appartiennent aux catégories suivantes :

  • Les charges de travail transactionnelles incluent des applications interactives telles que la vente, le traitement financier, la planification des ressources d'entreprise ou la communication.

  • Les charges de travail analytiques incluent des applications qui transforment, analysent, affinent ou visualisent des données pour faciliter les processus de prise de décision.

Bien que les systèmes analytiques obtiennent leurs données à partir de systèmes transactionnels en interrogeant des API ou en accédant à des bases de données, dans la plupart des entreprises, les systèmes analytiques et transactionnels ont tendance à être séparés et faiblement couplés. Le concept d'analytique hybride/multicloud consiste à miser sur cette division préexistante en exécutant les deux types de charges de travail dans deux environnements informatiques différents. Les données brutes sont d'abord extraites des charges de travail exécutées dans l'environnement informatique privé, puis chargées dans GCP, où elles sont utilisées à des fins de traitement analytique. Certains résultats pourraient ensuite être renvoyés aux systèmes transactionnels.

modèle analytique multicloud

Avantages

L'exécution de charges de travail analytiques dans le cloud présente plusieurs avantages essentiels :

  • Les charges de travail analytiques doivent souvent traiter des quantités importantes de données et peuvent être exécutées en rafale. Elles sont donc particulièrement bien adaptées au déploiement dans un environnement de cloud public. En mettant à l'échelle les ressources de calcul de manière dynamique, vous pouvez traiter rapidement des ensembles de données volumineux tout en évitant les investissements initiaux ou toute surestimation de vos besoins en matériel informatique.

  • GCP fournit un ensemble complet de services permettant de gérer les données tout au long de leur cycle de vie, de leur acquisition initiale à leur visualisation finale, en passant par leur traitement et leur analyse.

  • Cloud Storage est parfaitement adapté à la construction d'un lac de données.

  • Le trafic entrant (transfert de données entre l'environnement informatique privé et GCP) est gratuit.

Bonnes pratiques

Pour mettre en œuvre le modèle d'analyse hybride/multicloud, tenez compte des bonnes pratiques suivantes :

  • Utilisez la topologie de transfert pour permettre l’ingestion de données. Si les résultats analytiques doivent être renvoyés aux systèmes transactionnels, combinez les topologies de transfert et de sortie contrôlée.

  • Utilisez les files d'attente Cloud Pub/Sub ou les buckets Cloud Storage pour transférer des données à GCP à partir de systèmes transactionnels exécutés dans votre environnement informatique privé. Ces files d'attente ou buckets peuvent ensuite servir de sources pour les pipelines de traitement de données et les charges de travail.

  • Lorsque vous avez des charges de travail Hadoop ou Spark existantes, envisagez de migrer les tâches vers Cloud Dataproc et de migrer les données HDFS existantes vers Cloud Storage.

  • Lorsque vous effectuez un premier transfert de données de votre environnement informatique privé vers GCP, choisissez la méthode de transfert la mieux adaptée à la taille de votre ensemble de données et à la bande passante disponible.

  • Utilisez des outils et des processus cohérents dans tous les environnements. Dans un scénario d'analyse hybride, cette pratique peut contribuer à accroître l'efficacité opérationnelle, bien qu'elle ne constitue pas une condition préalable.

Hybride de périphérie

Pour exécuter des charges de travail dans le cloud, les clients doivent disposer d'une connectivité Internet rapide et fiable. Compte tenu des réseaux actuels, cette exigence pose rarement un défi pour les projets d'adoption du cloud. Il existe cependant des scénarios dans lesquels vous ne pouvez pas compter sur une connectivité continue :

  • Les plates-formes pétrolières, les navires et autres véhicules peuvent n'être connectés que de manière intermittente ou n’avoir accès qu’aux liaisons satellite à latence élevée.

  • Les usines ou les centrales peuvent être connectées à Internet. Ces installations peuvent cependant avoir des exigences de fiabilité dépassant les garanties de disponibilité offertes par la liaison.

  • Les magasins ou les supermarchés peuvent n'être connectés que de manière occasionnelle ou utiliser des liens n'offrant pas la fiabilité ou le débit nécessaires pour traiter des transactions critiques.

Le modèle hybride de périphérie résout ces problèmes en exécutant les charges de travail urgentes et stratégiques localement, à la périphérie du réseau, tout en utilisant le cloud pour tous les autres types de charges de travail. Dans une configuration hybride de périphérie, le lien Internet est un composant non critique utilisé à des fins de gestion et de synchronisation ou de chargement de données, souvent de manière asynchrone, mais n'intervenant pas dans des transactions urgentes ou critiques.

modèle hybride de périphérie

Avantages

Le fait d'exécuter certaines charges de travail à la périphérie et d'autres dans le cloud offre plusieurs avantages :

  • L'exécution de charges de travail urgentes et stratégiques à la périphérie permet de garantir une faible latence et une autosuffisance. Si la connexion Internet échoue ou est temporairement indisponible, vous pouvez toujours exécuter toutes les transactions importantes. Dans le même temps, vous pouvez tirer parti de l'utilisation du cloud pour une part importante de votre charge de travail globale.

  • Vous pouvez réutiliser des investissements informatiques et de stockage existants.

  • Au fil du temps, vous pouvez réduire progressivement la fraction de charges de travail exécutées en périphérie, soit en retravaillant certaines applications, soit en dotant certains emplacements de périphérie de liens Internet plus fiables.

  • Le trafic entrant (transfert de données de la périphérie vers GCP) est gratuit.

Bonnes pratiques

Tenez compte des recommandations suivantes lorsque vous implémentez le modèle hybride de périphérie :

  • Si la communication est unidirectionnelle, utilisez la topologie d’entrée contrôlée. Dans le cas d'une communication bidirectionnelle, tenez compte de la topologie d'entrée et de sortie contrôlées.

  • Minimisez les dépendances entre les systèmes exécutés en périphérie et ceux exécutés dans l'environnement cloud. Chaque dépendance peut compromettre les avantages en termes de fiabilité et de latence d'une configuration hybride de bord.

  • Pour gérer et exploiter efficacement plusieurs emplacements périphériques, utilisez un plan de contrôle centralisé dans le cloud.

  • Assurez-vous que les processus CI/CD ainsi que les outils de déploiement et de surveillance sont cohérents dans les environnements cloud et périphériques.

  • Songez à utiliser des conteneurs et Kubernetes pour éliminer les différences entre les divers emplacements périphériques, ainsi qu’entre les emplacements périphériques et le cloud. Étant donné que Kubernetes fournit une couche d'exécution commune, vous pouvez développer, exécuter et utiliser des charges de travail de manière cohérente dans tous les environnements informatiques et déplacer des charges de travail entre la périphérie et le cloud.

  • Établissez une identité commune entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée au-delà des limites de l'environnement.

  • Les données échangées entre environnements pouvant être sensibles, assurez-vous que toutes les communications sont chiffrées en utilisant des tunnels VPN, TLS ou les deux.

Modèles de déploiement redondant

Les sections suivantes explorent les modèles courants qui reposent sur un déploiement redondant d'applications dans plusieurs environnements informatiques. Dans ces modèles, vous déployez les mêmes applications dans plusieurs environnements informatiques dans le but d'accroître la capacité ou la résilience.

Environnement hybride

Le concept de modèle d'environnement hybride consiste à conserver l'environnement de production d'une charge de travail dans le centre de données existant, tout en utilisant le cloud public pour d'autres environnements non productifs.

En évaluant les charges de travail à migrer, vous remarquerez peut-être des cas où l'exécution d'une application spécifique dans le cloud public pose certains défis :

  • Des contraintes juridictionnelles ou réglementaires peuvent nécessiter que vous conserviez des données dans un pays spécifique.
  • Des conditions de licence tierces peuvent vous empêcher d’utiliser certains logiciels dans un environnement cloud.
  • Une application peut nécessiter un accès à des périphériques matériels disponibles seulement localement, comme lors du déplacement de charges de travail.

Dans de tels cas, vous devez tenir compte non seulement de l'environnement de production, mais également de tous les environnements impliqués dans le cycle de vie d'une application, y compris les systèmes de développement, de test et de préproduction. Les restrictions pouvant rendre difficile la migration vers le cloud s’appliquent souvent à l’environnement de production et à ses données, mais pas aux autres environnements.

Le schéma suivant illustre un modèle d’environnement hybride typique.

modèle d'environnement hybride

Le fait de faire fonctionner des systèmes de développement et de test dans des environnements différents de ceux des systèmes de production peut sembler risqué et aller à l’encontre des bonnes pratiques existantes ou des tentatives visant à minimiser les différences entre de tels environnements. Bien que ces préoccupations soient justifiées, elles ne s'appliquent pas si vous faites une distinction entre les étapes des processus de développement et de test :

  • Bien que les processus de développement, de test et de déploiement diffèrent d'une application à l'autre, ils impliquent généralement des variantes des étapes suivantes :

    • Développement : créer une version finale
    • Tests fonctionnels ou tests d'acceptation utilisateur : vérifier que la version finale répond aux exigences fonctionnelles
    • Tests de performance et de fiabilité : vérifier que la version finale répond aux exigences non fonctionnelles.
    • Tests de préproduction ou de déploiement : vérifier que la procédure de déploiement fonctionne
    • Production

L'exécution de plusieurs de ces étapes dans un seul environnement est rarement pratique. Chaque étape nécessite donc généralement un ou plusieurs environnements dédiés.

Pour que les résultats de test soient significatifs et s'appliquent au déploiement de production, les environnements que vous utilisez tout au long du cycle de vie d'une application doivent tous respecter les règles suivantes, dans la mesure du possible :

  • Tous les environnements sont équivalents du point de vue fonctionnel. En d'autres termes, l'architecture, les API et les versions des systèmes d'exploitation et des bibliothèques sont équivalentes et les systèmes se comportent de la même manière dans tous les environnements. Cette équivalence permet d'éviter des situations où les applications fonctionneraient dans un environnement mais échoueraient dans un autre, ou dans lesquelles les défaillances ne seraient pas reproductibles.

  • Les environnements utilisés pour les tests de performance et de fiabilité, la préproduction et la production sont équivalents d'un point de vue non fonctionnel. Autrement dit, leurs performances, leur échelle et leur configuration, ainsi que la manière dont ils sont utilisés et maintenus, sont identiques ou ne diffèrent que de manière peu significative. Les tests de performance et de préproduction deviendraient autrement dénués de sens.

Il est essentiel que les environnements utilisés pour le développement et les tests fonctionnels diffèrent des autres environnements du point de vue non fonctionnel. Cette situation s’accorde bien avec le modèle d’environnement hybride :

  • Parvenez à une équivalence fonctionnelle entre tous les environnements en utilisant Kubernetes en tant que couche d'exécution commune pour garantir la portabilité des charges de travail et éliminer les différences entre les environnements informatiques.

  • Exécutez les environnements des tests de production, préproduction, performance et fiabilité dans l'environnement informatique privé, en veillant à avoir une équivalence des points de vue fonctionnel et non fonctionnel.

  • Exécutez les environnements de développement et de tests fonctionnels dans le cloud public. Ces environnements sont équivalents aux environnements restants du point de vue fonctionnel, mais peuvent différer les uns des autres sur certains aspects non fonctionnels tels que les performances.

Avantages

L'exécution de charges de travail de développement et de tests fonctionnels dans le cloud public présente plusieurs avantages :

  • Vous pouvez automatiquement créer et détruire des environnements selon vos besoins. Par exemple, vous pouvez configurer un environnement complet pour chaque requête commit ou pull, autoriser l'exécution des tests, puis le détruire.

  • Les environnements de développement et de test sont souvent utilisés de manière intermittente. Vous pouvez réduire vos coûts en arrêtant les instances de machine virtuelle (VM) pendant les périodes d'inactivité ou en ne provisionnant des environnements qu'à la demande.

  • En exécutant ces environnements dans le cloud public, vous pourrez vous familiariser avec le cloud et les outils associés et les utiliser avec une confiance accrue, ce qui pourrait faciliter la migration d'autres charges de travail.

Bonnes pratiques

Pour implémenter correctement le modèle d’environnement, tenez compte des recommandations suivantes :

  • Utilisez la topologie en miroir pour empêcher les systèmes de différents environnements de communiquer entre eux. Comme les systèmes n'ont pas besoin de communiquer entre différents environnements, vous n'avez pas besoin d'établir une identité commune.

  • Utilisez à la fois des conteneurs et Kubernetes pour rendre les charges de travail portables et pour éliminer les différences qui existent entre les environnements, mais tenez compte des limites en termes de portabilité des charges de travail.

  • Assurez-vous que les processus CI/CD sont cohérents dans tous les environnements informatiques et que le même ensemble de fichiers binaires, de paquets ou de conteneurs est déployé dans les différents environnements.

  • Pour déployer, configurer et utiliser des charges de travail, mettez en place une chaîne d'outils commune qui fonctionne dans plusieurs environnements informatiques. L'utilisation de Kubernetes vous donnera cette cohérence, à l'exception de quelques différences mineures dans la manière dont vous vous connectez ou vous vous authentifiez aux clusters exécutés dans différents environnements informatiques.

  • Lorsque vous utilisez Kubernetes, utilisez un système de CI tel que Jenkins pour implémenter un pipeline de déploiement qui se déploie sur des clusters et fonctionne dans différents environnements. Vous pouvez également exécuter Jenkins lui-même sur Google Kubernetes Engine (GKE).

  • Utilisez les mêmes outils pour la journalisation et la surveillance dans les environnements GCP et cloud existants. Songez à utiliser des systèmes de surveillance Open Source tels que Prometheus. Si différentes équipes gèrent les charges de travail de test et de production, il peut être acceptable dans ce cas d'utiliser des outils distincts, même si le fait d'utiliser les mêmes outils pourrait entraîner une simplicité accrue et réduire le besoin de formation.

  • Lorsque vous choisissez des services de base de données, de stockage et de messagerie, utilisez des produits ayant un équivalent géré sur GCP. Le recours à des services gérés permet de réduire les tâches administratives liées à la maintenance des environnements de développement et de test. Le tableau suivant indique les produits GCP compatibles avec les produits OSS courants.

Produit OSS Produit GCP compatible
Apache HBase Cloud Bigtable
Apache Beam Cloud Dataflow
Apache Hadoop Cloud Dataproc
MySQL, PostgreSQL Cloud SQL
Redis Cloud Memorystore
Système de fichiers réseau (NFS) Cloud Filestore
JMS, Kafka Cloud Pub/Sub

Continuité d'activité hybride/multicloud

Idéalement, les systèmes critiques sont configurés de manière à être résilients en cas de catastrophe. En répliquant les systèmes et les données sur plusieurs régions géographiques et en évitant les points de défaillance uniques, vous pouvez minimiser les risques de catastrophe naturelle affectant les infrastructures locales. Cependant, cette approche ne résout pas le risque de pannes causées par une erreur humaine ou des défauts logiciels. Par conséquent, il est essentiel de disposer également d'un plan de reprise après sinistre vous permettant de restaurer vos systèmes dans des délais acceptables et avec une perte de données minimale si d'autres types de sinistres se produisent.

Un élément clé de la planification de reprise après sinistre consiste à sauvegarder fréquemment les données dans des emplacements géographiques différents afin de réduire l'objectif de point de reprise (RPO). Par ailleurs, le maintien de systèmes de secours manuels, semi-automatiques ou automatiques dans un deuxième emplacement peut aider à réduire l'objectif de temps de reprise (RTO).

Lorsque vous exécutez des systèmes critiques dans un centre de données central, une solution pour la reprise après sinistre consiste à gérer les systèmes de secours dans un deuxième centre de données situé dans une autre région. Une approche plus rentable consiste toutefois à utiliser un environnement informatique basé sur un cloud public à des fins de basculement, ce à quoi correspond le concept de modèle de continuité d'activité hybride.

modèle de continuité d'activité hybride

Une variante moins courante (et rarement requise) de ce modèle est le modèle de continuité d'activité multicloud, dans lequel l'environnement de production utilise un fournisseur cloud et l'environnement de reprise après sinistre utilise un fournisseur cloud différent. En déployant des copies de charges de travail auprès de plusieurs fournisseurs cloud, vous pouvez obtenir une disponibilité supérieure à celle proposée par un déploiement multirégion.

Avantages

L'utilisation du cloud public pour la continuité des activités offre de nombreux avantages :

  • Comme propose un choix de plus d'une douzaine de régions, vous pouvez l'utiliser pour sauvegarder ou répliquer des données sur un site différent du même continent, ou même sur un site d'un autre continent.

  • Les instances de VM arrêtées n'engendrent que des coûts de stockage et sont nettement moins chères que les instances de VM en cours d'exécution. Vous pouvez ainsi réduire les coûts liés à la maintenance des systèmes de secours manuels.

  • Le modèle de tarification à l'utilisation de GCP garantit que vous ne payez que pour le stockage et la capacité de calcul que vous utilisez réellement, et vous pouvez agrandir ou réduire votre environnement de reprise après sinistre selon vos besoins.

Bonnes pratiques

Lorsque vous utilisez le modèle de continuité d'activité, tenez compte des bonnes pratiques suivantes :

  • Créez un plan de reprise après sinistre qui documente votre infrastructure, ainsi que les procédures de basculement et de récupération.

  • En fonction de votre RPO et de votre RTO, décidez si la sauvegarde des données sur GCP est suffisante ou si vous devez conserver des systèmes de secours manuels, semi-automatiques ou automatiques. Reportez-vous au Guide de planification de la reprise après sinistre pour connaître les scénarios courants et obtenir des conseils pour les implémenter dans GCP.

  • Lorsque vous n'effectuez que des sauvegardes de données, utilisez la topologie de transfert. Sinon, envisagez la topologie en miroir.

  • Réduisez les dépendances entre les systèmes exécutés dans des environnements différents, en particulier lorsque la communication est gérée de manière synchrone. Ces dépendances peuvent ralentir les performances et réduire la disponibilité globale.

  • Si vous répliquez des données de manière bidirectionnelle sur plusieurs environnements, vous pouvez être exposé au problème de Split-Brain. Si la communication entre les deux environnements est interrompue, les systèmes peuvent en effet conclure chacun de leur côté que l'autre environnement n'est plus disponible. Les systèmes peuvent en conclure qu'ils disposent d'un accès exclusif aux données, ce qui conduit à terme à des modifications contradictoires. Un moyen d'éviter ce fractionnement consiste à ajouter un troisième environnement informatique. Cette approche permet en effet à un système qui s'appuie sur la réplication de données de vérifier la présence d'un quorum avant de conclure que la modification des données ne présente aucun risque. Vous pouvez également autoriser le rapprochement des modifications de données en conflit après la restauration de la connectivité.

  • Assurez-vous que les systèmes CI/CD et les dépôts d'artefacts ne se transforment pas en point de défaillance unique. Lorsqu'un environnement est indisponible, vous devez toujours pouvoir déployer de nouvelles versions ou appliquer des modifications de configuration.

  • Les données échangées entre différents environnements pouvant être sensibles, assurez-vous que toutes les communications sont chiffrées en utilisant des tunnels VPN, TLS ou les deux.

  • Lorsque vous utilisez des systèmes de secours, assurez-vous que les charges de travail sont portables afin que les systèmes restent cohérents dans tous les environnements. Songez à utiliser des conteneurs et Kubernetes.

  • Intégrez le déploiement de systèmes de secours dans votre processus CI/CD. Cette intégration permet de garantir la cohérence des versions et des configurations d'applications dans tous les environnements.

  • Lorsque vous utilisez des systèmes de secours automatiques, utilisez des équilibreurs de charge pour créer un basculement automatique, mais gardez à l'esprit que les équilibreurs de charge peuvent eux aussi échouer. Par précaution, configurez votre DNS de sorte à pouvoir rediriger les utilisateurs vers des systèmes de secours en cas de sinistre. Utilisez une valeur TTL relativement courte pour veiller à ce que les modifications DNS soient propagées rapidement, et utilisez la garantie de disponibilité à 100 % offerte par Cloud DNS.

  • Pour la reprise après sinistre, envisagez des solutions partenaires telles que CloudEndure, Actifio et Commvault.

Utilisation temporaire du cloud

Les applications Internet, en particulier celles qui ciblent les utilisateurs, peuvent connaître des fluctuations d’utilisation extrêmes. Bien que la plupart des applications d'entreprise ne soient pas confrontées à ce problème, de nombreuses entreprises doivent faire face à un type de charges de travail intensives différent : les tâches par lots ou CI/CD.

Bien que vous puissiez gérer des charges de travail intensives dans un environnement informatique classique basé sur un centre de données en approvisionnant des ressources en quantité excessive, cette approche n'est pas rentable. Avec les tâches par lots, vous pouvez optimiser leur utilisation en différant leur exécution sur des périodes plus longues, bien qu'il ne soit pas pratique de retarder les tâches si elles sont urgentes.

Le concept de modèle d'utilisation temporaire du cloud consiste à utiliser un environnement informatique privé pour la charge de base et à se connecter temporairement au cloud en cas de besoins de capacité accrus.

modèle d'utilisation temporaire du cloud

La portabilité des charges de travail est une condition essentielle pour les scénarios d'utilisation temporaire du cloud. Lorsque vous autorisez le déploiement de charges de travail dans plusieurs environnements, vous devez supprimer les différences qui existent entre ces environnements.

Le modèle d'utilisation temporaire du cloud s'applique aussi bien aux charges de travail interactives et par lots. Toutefois, lorsque vous traitez des charges de travail interactives, vous devez déterminer comment répartir les requêtes entre les différents environnements :

  • Vous pouvez acheminer les requêtes entrantes des utilisateurs vers un équilibreur de charge exécuté dans le centre de données existant, puis faire en sorte que l'équilibreur de charge répartisse les requêtes entre les ressources locales et cloud. Cette approche nécessite que l'équilibreur de charge ou un autre système en cours d'exécution dans le centre de données existant procède également au suivi des ressources allouées dans le cloud et qu'il initie une augmentation ou une diminution automatique des ressources.

    image

    D'un côté, cette approche vous permet de mettre toutes les ressources cloud hors service en période de faible activité. D'un autre, la mise en place de mécanismes capables de procéder au suivi des ressources pourrait aller au-delà des capacités des solutions d'équilibrage de charge disponibles dans le commerce et augmenter ainsi la complexité globale.

  • Sinon, vous pouvez commencer par acheminer les requêtes vers GCP pour les répartir ensuite entre les différents environnements. Étant donné que les équilibreurs de charge GCP ne prennent en charge l'équilibrage et l'autoscaling qu'entre les ressources GCP, vous devez associer un équilibreur de charge GCP à des mécanismes d'équilibrage de charge personnalisés supplémentaires pour faciliter la distribution des requêtes. Encore une fois, cette approche crée un surcroît de complexité.

    L'équilibrage de charge à l'aide d'un DNS à répétition alternée n'est pas pratique si vous avez l'intention de fermer toutes les ressources dans GCP pendant les périodes de faible demande. Comme les mises à jour DNS ont tendance à se propager lentement, l'utilisation de DNS pour l'équilibrage de la charge comporte le risque que les utilisateurs soient routés vers GCP lorsqu'aucune ressource n'est disponible pour traiter leurs requêtes.

Face à ces défis, l'utilisation temporaire du cloud se prête généralement mieux aux charges de travail par lots qu'aux charges de travail interactives.

Avantages

Les principaux avantages de ce modèle d'architecture sont les suivants :

  • L'utilisation temporaire du cloud vous permet de réutiliser des centres de données et environnements informatiques privés existants. Cette réutilisation peut être permanente ou temporaire jusqu’à ce que les équipements existants soient remplacés. Vous pouvez alors envisager une migration complète vers le cloud.

  • Vous pourrez peut-être augmenter l'utilisation et la rentabilité de vos environnements informatiques privés, car vous n'aurez plus besoin de conserver une capacité excédentaire pour répondre aux pics de requêtes.

  • L'utilisation temporaire du cloud permet d'exécuter les tâches par lots en temps voulu sans qu'il soit nécessaire de provisionner des ressources de calcul supplémentaires.

Bonnes pratiques

Lorsque vous mettez en œuvre le modèle d'utilisation temporaire du cloud, tenez compte des bonnes pratiques suivantes :

  • Utilisez la topologie maillée pour vous assurer que les charges de travail exécutées dans le cloud peuvent accéder aux ressources de la même manière que les charges de travail exécutées dans d'autres environnements informatiques. Si les charges de travail le permettent, n'autorisez l'accès que du cloud vers l'autre environnement informatique, et non l'inverse.

  • Pour minimiser la latence des communications entre les environnements, choisissez une région GCP et un emplacement d'interconnexion géographiquement proches de votre environnement informatique privé.

  • Lorsque vous utilisez le modèle d'utilisation temporaire du cloud pour des charges de travail par lots seulement, réduisez la surface d'attaque de sécurité en gardant toutes les ressources GCP privées et en interdisant tout accès direct à ces ressources depuis Internet.

  • Pour les tâches qui ne durent pas plus de 24 heures et ne nécessitent pas beaucoup de temps, envisagez d'utiliser des instances de VM préemptibles, qui reviennent nettement moins cher que les instances de VM classiques. Toutefois, une condition préalable est que, si la VM sur laquelle une tâche est en cours d'exécution est préemptée, le système doit pouvoir la redémarrer automatiquement.

  • Utilisez des conteneurs pour assurer la portabilité des charges de travail. Pour les charges de travail par lots nécessitant beaucoup de ressources, vous pouvez déployer directement ces conteneurs sur des VM Compute Engine et utiliser un groupe d'instances gérées pour mettre à l'échelle le nombre de VM. Dans le cas de charges de travail interactives ou de charges de travail diverses nécessitant moins de ressources, vous pouvez également utiliser Google Kubernetes Engine (GKE) en combinaison avec l'autoscaling de clusters pour déployer ces conteneurs. Notez cependant que GKE nécessite au moins un nœud par zone pour être exécuté en permanence.

  • Surveillez tout trafic envoyé depuis GCP vers un environnement informatique différent. Ce trafic est soumis à des frais de sortie.

  • Les données échangées entre différents environnements pouvant être sensibles, assurez-vous que toutes les communications sont chiffrées en utilisant des tunnels VPN, TLS ou les deux.

  • Pour les charges de travail nécessitant beaucoup de stockage, envisagez l'intégration à une solution de stockage hybride comme Cloudian, ClearSky, Avere vFXT, Egnyte ou SwiftStack.

  • Utilisez le modèle d'utilisation temporaire du cloud pour mettre à l'échelle un système CI de manière dynamique. Si vous utilisez Jenkins, vous pouvez utiliser le plug-in Google Compute Engine pour gérer les instances Jenkins sur Compute Engine et procéder à leur autoscaling.

  • Établissez une identité commune entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée au-delà des limites de l'environnement.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…