Modèle de mise à l’échelle intercloud

Ajoutez automatiquement des ressources à une application existante pour prendre en charge une augmentation de la charge.

Contexte et problème

Votre application ne peut pas augmenter la capacité pour répondre à des augmentations inattendues de la demande. Ce manque d’extensibilité entraîne l’absence d’accès des utilisateurs à l’application pendant les pics d’utilisation. L’application peut traiter un nombre fixe d’utilisateurs.

Les entreprises mondiales nécessitent des applications cloud sécurisées, fiables et disponibles. Répondre aux augmentations de la demande et utiliser l’infrastructure appropriée pour prendre en charge cette demande est essentielle. Les entreprises ont du mal à équilibrer les coûts et la maintenance avec la sécurité, le stockage et la disponibilité en temps réel des données métiers.

Vous ne pourrez peut-être pas exécuter votre application dans le cloud public. Toutefois, il n’est peut-être pas possible économique pour l’entreprise de maintenir la capacité requise dans son environnement local pour gérer les pics de demande de l’application. Avec ce modèle, vous pouvez utiliser l’élasticité du cloud public avec votre solution locale.

Solution

Le modèle de mise à l’échelle intercloud étend une application située dans un cloud local avec des ressources de cloud public. Le modèle est déclenché par une augmentation ou une diminution de la demande, et ajoute ou supprime respectivement des ressources dans le cloud. Ces ressources fournissent une redondance, une disponibilité rapide et un routage géo-conforme.

Remarque

Ce modèle s’applique uniquement aux applications sans état de votre application.

Composants

Le modèle de mise à l’échelle intercloud se compose des composants suivants.

En dehors du cloud

Gestionnaire du trafic

Dans le diagramme, il se trouve en dehors du groupe de cloud public, mais il faudrait pouvoir coordonner le trafic dans le centre de données local et le cloud public. L’équilibreur offre une haute disponibilité pour l’application en supervisant les points de terminaison et en assurant la redistribution du basculement en cas de besoin.

Système de noms de domaine (DNS)

Le système de noms de domaine ou DNS est responsable de la traduction (ou résolution) d’un nom de site web ou de service vers son adresse IP.

Nuage

Serveur de build hébergé

Environnement pour l’hébergement de votre pipeline de build.

Ressources de l’application

Les ressources d’application doivent pouvoir effectuer un scale-in et un scale-out, à l’image des groupes de machines virtuelles identiques et des conteneurs.

Nom de domaine personnalisé

Utilisez un nom de domaine personnalisé pour le routage des requêtes glob.

Adresses IP publiques

Les adresses IP publiques sont utilisées pour router le trafic entrant via Traffic Manager vers le point de terminaison des ressources d’application cloud public.  

Nuage local

Serveur de build hébergé

Environnement pour l’hébergement de votre pipeline de build.

Ressources de l’application

Les ressources d’application doivent pouvoir effectuer un scale-in et un scale-out, à l’image des groupes de machines virtuelles identiques et des conteneurs.

Nom de domaine personnalisé

Utilisez un nom de domaine personnalisé pour le routage des requêtes glob.

Adresses IP publiques

Les adresses IP publiques sont utilisées pour router le trafic entrant via Traffic Manager vers le point de terminaison des ressources d’application cloud public.

Problèmes et considérations

Tenez compte des points suivants lors de la décision d’implémenter ce modèle :

Extensibilité

Le composant clé de la mise à l’échelle intercloud est la possibilité de fournir une mise à l’échelle à la demande. La mise à l’échelle doit se produire entre l’infrastructure cloud publique et locale et fournir un service cohérent et fiable en fonction de la demande.

Disponibilité

Vérifiez que les applications déployées localement sont configurées pour la haute disponibilité via la configuration matérielle locale et le déploiement de logiciels.

Gérabilité

Le modèle intercloud garantit une gestion transparente et une interface familière entre les environnements.

Quand utiliser ce modèle

Utilisez ce modèle :

• Lorsque vous devez augmenter la capacité de votre application face à des demandes inattendues ou des demandes périodiques croissantes.
• Lorsque vous ne souhaitez pas investir dans des ressources qui ne seront utilisées que pendant les pics. Payez pour ce que vous utilisez.

Ce modèle n’est pas recommandé lorsque :

• Votre solution nécessite que les utilisateurs se connectent via Internet.
• Votre entreprise dispose de réglementations locales qui exigent que la connexion d’origine provient d’un appel sur site.
• Votre réseau rencontre des goulots d’étranglement réguliers qui limiteraient les performances de la mise à l’échelle.
• Votre environnement est déconnecté d’Internet et ne peut pas atteindre le cloud public.

Étapes suivantes

Pour en savoir plus sur les rubriques présentées dans cet article :

• Consultez la vue d’ensemble d’Azure Traffic Manager pour en savoir plus sur le fonctionnement de cet équilibreur de charge de trafic DNS.
• Consultez la famille de produits et de solutions Azure Stack pour en savoir plus sur l’ensemble du portefeuille de produits et de solutions.

Lorsque vous êtes prêt à tester l’exemple de solution, poursuivez avec le guide de déploiement de la solution de mise à l’échelle multicloud . Le guide de déploiement fournit des instructions pas à pas pour déployer et tester ses composants. Vous allez apprendre à créer une solution multicloud pour fournir un processus déclenché manuellement pour passer d’une application web hébergée par Azure Stack Hub à une application web hébergée par Azure. Vous allez également apprendre à utiliser la mise à l’échelle automatique via Traffic Manager, en garantissant un utilitaire cloud flexible et évolutif en cas de charge.