Déploiement d'une seule zone

Dans les déploiements à zone unique, plusieurs instances d'application sont déployées dans une zone. Si une instance d'application s'exécute dans un seul serveur virtuel, les groupes de placement permettent de provisionner ces serveurs virtuels dans des hôtes physiques distincts. VPC Autoscale peut être utilisé pour permettre un ajustement dynamique de la capacité en fonction de l'évolution de la charge de travail. Les déploiements en zone unique offrent des solutions rentables avec une disponibilité de l'infrastructure de 99.9 Ce déploiement peut convenir à des environnements de non-production ou à des applications non essentielles à l'activité de l'entreprise. Cependant, les déploiements à zone unique n'offrent aucune protection contre les pannes de zone.

Lorsque vous utilisez ce modèle de déploiement, il est recommandé d'éviter les déséquilibres entre les zones. On parle de déséquilibre entre les zones lorsque la capacité (par exemple, les instances de serveur virtuel VPC (VSI)) n'est pas répartie de manière uniforme entre les zones. Prenons l'exemple d'une charge de travail déployée avec 70 % de sa capacité VSI dans la zone 1, 20 % dans la zone 2 et 10 % dans la zone 3. En cas de défaillance de la zone 1, la charge de travail pourrait rester disponible, mais avec seulement 30 % de sa capacité. Une solution consiste à allouer davantage de ressources en cas de panne de la zone 1, mais cette panne peut entraîner un pic anormal de la demande de capacité dans les zones restantes. Une meilleure solution consiste à éliminer ce déséquilibre et à veiller à ce que la capacité requise soit répartie entre les zones, avec une marge supplémentaire d’environ 17 % dans chaque zone afin de compenser la perte d’une zone donnée. Cela garantit que la charge de travail reste disponible et peut fonctionner à pleine capacité, même en cas de perte d'une zone.

Déploiement multizone et mono-région

Dans le cas d'un déploiement multizone et monorégion, plusieurs instances d'application sont déployées dans deux zones de disponibilité ou plus au sein de la région. Les déploiements multi-zones au sein d’une même région peuvent offrir une disponibilité de l’infrastructure pouvant atteindre 99.99 % lorsque l’application est déployée sur trois zones de disponibilité. Ce déploiement protège l'application contre les pannes de zone et convient aux charges de travail d'entreprise en production nécessitant une disponibilité supérieure à 99.9 %. La disponibilité réelle de l'application dépend de la conception de la haute disponibilité de l'application.

Lorsque vous utilisez ce modèle de déploiement, évitez les déséquilibres entre les zones. Un déséquilibre entre les zones se produit lorsque la capacité — par exemple, les IBM Cloud® Virtual Servers for Virtual Private Cloud s (VSI) — n’est pas répartie de manière homogène entre les zones. Prenons l'exemple d'une charge de travail déployée avec 70 % de sa capacité VSI dans la zone 1, 20 % dans la zone 2 et 10 % dans la zone 3. En cas de défaillance de la zone 1, la charge de travail peut rester disponible, mais avec seulement 30 % de sa capacité. Vous pourriez provisionner davantage de ressources en cas de panne, mais celle-ci peut entraîner un pic anormal de la demande de capacité dans les zones restantes. Pour remédier à ce déséquilibre, répartissez la capacité requise de manière uniforme entre les zones, en prévoyant une marge supplémentaire d'environ 17 % par zone afin de compenser la perte éventuelle d'une zone donnée. Cela garantit que la charge de travail reste disponible et peut fonctionner à pleine capacité en cas de défaillance d'une zone.

Déploiement multizone et multirégion

Un déploiement multizone et multirégion assure une protection contre les pannes régionales. Ce déploiement est recommandé pour les applications critiques nécessitant une disponibilité continue ou quasi-continue. Ce déploiement prend également en charge la reprise après sinistre hors région et la continuité des activités pour les applications ayant des exigences géographiques ou de distance de séparation spécifiques.

Les déploiements multizones s'appuient sur la réplication des données en fonction des applications entre les zones de disponibilité et prennent en charge les modèles d'architecture active-active et active-standby. Les déploiements multizones et multirégions prennent en charge les modèles d'architecture pour les applications d'entreprise avec une disponibilité continue et des exigences de disponibilité permanente. Les tableaux suivants présentent une comparaison des différentes options de déploiement et de l'utilisation recommandée.

Le cadre d'architecture suivant fournit des considérations de conception et des décisions d'architecture pour le déploiement d'applications résilientes sur l'infrastructure IBM Cloud Virtual Private Cloud (VPC). Il couvre les aspects et domaines de solution suivants :

• Mise en réseau : Équilibrage de la charge, système de noms de domaine
• Sécurité : Sécurité des données
• Résilience : haute disponibilité, sauvegarde et restauration, reprise après sinistre
• Gestion des services : Surveillance, journalisation, audit, alerte

Le cadre de conception de l'architecture fournit une approche cohérente pour concevoir des solutions en nuage en répondant aux exigences à travers un ensemble d'aspects et de domaines. Les domaines sont des zones architecturales qui doivent être prises en compte pour toute solution d'entreprise, quelle que soit la technologie.

Logique de relance du client pour les applications hautement disponibles

Vous êtes responsable de la création d'applications clientes capables de gérer efficacement les erreurs temporaires. Les erreurs temporaires comprennent les erreurs de réseau et les défaillances temporaires introduites par la mise en œuvre de la haute disponibilité d'un service, par exemple lorsqu'un service régional se remet d'une défaillance zonale. Pour plus d'informations sur les services spécifiques IBM Cloud, voir la documentation sur les services de haute disponibilité et de reprise après sinistre.

De nombreux IBM Cloud Sont construits sur le IBM Cloud SDK Common qui prend en charge les tentatives automatiques conçues pour gérer des erreurs HTTP spécifiques, telles que les erreurs 429 et 503. Le SDK ne traite pas toutes les erreurs automatiquement. Pour tirer parti de la logique de réessai, vous devez configurer correctement le SDK.

Certains services IBM Cloud prennent en charge des protocoles open source, et il peut être approprié d'utiliser des SDK open source. Examinez ces SDK pour déterminer s'ils sont utiles à votre application et s'ils offrent des fonctions de relance appropriées.

La logique de réessai varie en fonction du type de service IBM Cloud et du type d'opération. Certaines opérations échouées produisent des codes d'état adaptés aux tentatives, tandis que d'autres produisent des codes d'état qui ne sont pas adaptés aux tentatives. Les opérations de lecture et HTTP GET qui échouent peuvent généralement être réessayées en utilisant un backoff exponentiel avec une période de temps fixe. Le backoff exponentiel est une stratégie de relance qui permet de gérer les nouvelles tentatives après l'échec d'une opération, telle qu'une requête réseau ou un appel à l'API. Il augmente progressivement le délai entre les tentatives selon un schéma exponentiel, ce qui réduit le risque de surcharge du système. Les défaillances qui doivent être retentées dépendent du type de défaillance et du service IBM Cloud spécifique. Pour plus d'informations, consultez la documentation et le SDK des services IBM Cloud

Les échecs des opérations write, HTTP PUT, POST, DELETE et autres ne sont probablement pas récupérables à l'aide d'un simple mécanisme de réessai, sauf s'il est clair que l'opération ne s'est pas terminée et que la logique documentée du client indique qu'un réessai est approprié. Lorsqu'une opération qui modifie l'état d'un système, comme la création d'une ressource, échoue, la cause de l'échec n'est souvent pas claire. En raison de cette incertitude, vous ne pouvez pas compter sur une simple logique de réessai pour résoudre le problème. Utilisez plutôt des méthodes plus avancées conçues spécifiquement pour le service IBM Cloud

La relance du client améliore la disponibilité d'un seul client, et les charges de travail peuvent être composées de nombreux clients. L'enregistrement des défaillances des clients dans un service d'enregistrement centralisé tel que IBM Cloud Logs permet d'analyser les défaillances et la disponibilité de l'ensemble de la charge de travail.