Partage via

Fiabilité dans Azure Batch

  • Article

Cet article décrit la prise en charge de la fiabilité dans Azure Batch et couvre la résilience intra-régionale avec les zones de disponibilité. Il fournit également des liens vers des informations sur la reprise d’activité et la continuité d’activité entre régions.

Prise en charge des zones de disponibilité

Les zones de disponibilité Azure sont au moins trois groupes physiquement distincts de centres de données dans chaque région Azure. Les centres de données de chaque zone sont équipés d’une infrastructure réseau, de refroidissement et d’alimentation indépendante. En cas de défaillance de zone locale, les zones de disponibilité sont conçues de telle sorte que si une zone est affectée, les services, la capacité et la haute disponibilité de la région sont pris en charge par les deux autres zones.

Les défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. La tolérance aux défaillances est obtenue par la redondance et l’isolation logique des services Azure. Pour obtenir des informations détaillées sur les zones de disponibilité dans Azure, consultez Régions et zones de disponibilité.

Les services Azure compatibles avec les zones de disponibilité sont conçus pour fournir le niveau approprié de fiabilité et de flexibilité. Ils peuvent être configurés de deux façons. Un service peut être redondant interzone, avec une réplication automatique entre les zones, ou zonal, avec des instances épinglées à une zone spécifique. Vous pouvez également combiner ces approches. Pour plus d’informations sur l’architecture zonale et redondante interzone, consultez Recommandations pour l’utilisation de zones de disponibilité et de régions.

Batch maintient la parité avec Azure pour la prise en charge de zones de disponibilité.

Prérequis

  • Pour les comptes Batch en mode abonnement utilisateur, assurez-vous que l’abonnement dans lequel vous créez votre pool n’a pas de restriction d’offre de zone sur la référence SKU de machine virtuelle requise. Pour voir si votre abonnement n’a pas de restrictions, appelez l’API Resource Skus List et vérifiez .ResourceSkuRestrictions Si une restriction de zone existe, vous pouvez envoyer un ticket de support pour supprimer la restriction de zone.

  • Puisque InfiniBand ne prend pas en charge la communication inter-zone, vous ne pouvez pas créer un pool avec une stratégie zonale si la communication entre les nœuds est activée et utilise une référence SKU de machine virtuelle qui prend en charge InfiniBand.

  • Batch maintient la parité avec Azure pour la prise en charge de zones de disponibilité. Pour utiliser l’option zonale, votre pool doit être créé dans une région Azure avec prise en charge des zones de disponibilité.

  • Pour allouer votre pool Batch dans les différentes zones de disponibilité, la région Azure dans laquelle le pool était créé doit prendre en charge la référence SKU de machine virtuelle requise dans plusieurs zones. Pour vérifier que la région prend en charge la référence SKU de machine virtuelle demandée dans plusieurs zones, appelez l’API Resource Skus List et vérifiez le locationInfo champ de resourceSku. Assurez-vous que plus d’une zone est prise en charge pour la référence SKU de machine virtuelle requise. Vous pouvez également utiliser Azure CLI pour répertorier toutes les références SKU de ressources disponibles avec la commande suivante :

    
    az vm list-skus

Créer un pool Azure Batch dans des zones de disponibilité

Pour obtenir des exemples sur la création d’un pool Batch dans des zones de disponibilité, consultez Créer un pool de Azure Batch à travers les zones de disponibilité.

Découvrez-en plus sur la création de comptes Batch avec le portail Azure, l’interface Azure CLI, PowerShell ou l’API Gestion du service Batch.

Expérience en cas de panne de zone

Lors d’une panne de zone, les nœuds de cette zone deviennent indisponibles. Tous les nœuds de ce même pool de nœuds provenant d’autres zones ne sont pas affectés et continuent d’être disponibles.

Azure Batch compte ne réalloue pas ou ne crée pas de nouveaux nœuds pour compenser les nœuds qui sont tombés en panne en raison de la panne. Les utilisateurs doivent ajouter d’autres nœuds au pool de nœuds, qui sont ensuite alloués à partir d’autres zones saines.

Tolérance de panne

Pour vous préparer à une possible défaillance de la zone de disponibilité, vous devez surdimensionner la capacité de service pour veiller à ce que la solution puisse tolérer une perte de capacité d’un tiers et continue à fonctionner sans dégradation des performances pendant les pannes à l’échelle de la zone. Étant donné que la plateforme répartit les machines virtuelles dans trois zones et que vous devez prendre en compte au moins la défaillance d’une zone, multipliez le nombre d’instances nécessaires pour un pic de charge de travail par un facteur de zones/(zones-1), soit 3/2. Par exemple, si votre pic de charge de travail typique nécessite quatre instances, vous devez en approvisionner six : (2/3 * 6 instances) = 4 instances.

Migration de zones de disponibilité

Vous ne pouvez pas migrer un pool Batch existant vers la prise en charge des zones de disponibilité. Si vous souhaite recréer votre pool Batch dans des zones de disponibilité, consultez Créer un pool de Azure Batch sur zones de disponibilité.

Reprise d’activité et continuité d’activité entre régions

Azure Batch est disponible dans toutes les régions Azure. Cependant, lorsqu'un compte Batch est créé, il doit être associé à une région spécifique. Toutes les prochaines opérations pour ce compte Batch s’appliquent seulement sur cette région. Par exemple, les pools et les machines virtuelles associées à ceux-ci sont créés dans la même région que le compte Batch.

Lorsque vous concevez une application qui utilise Batch, vous devez prendre en compte la possibilité que Batch pourrais ne pas être disponible dans une région. Même si ce cas de figure est rare, il peut arriver qu'un problème touche la région toute entière ou l'ensemble du service Batch de celle-ci, ou votre compte Batch spécifique.

Si l'application ou la solution qui utilise Batch doit toujours être disponible, elle doit être conçue de manière à pouvoir basculer vers une autre région ou à répartir la charge de travail entre deux ou plusieurs régions. Les deux approches nécessitent au moins deux comptes Batch situés dans des régions distinctes.

Vous êtes responsable de la configuration de la récupération d’urgence inter-régions avec Azure Batch. Si vous exécutez plusieurs comptes Batch dans des régions spécifiques et que vous tirez parti des zones de disponibilité, votre application peut répondre à vos objectifs de récupération d’urgence quand l’un de vos comptes Batch devient indisponible.

Pour basculer une solution vers une autre région, tous ses composants doivent être pris en compte ; un deuxième compte Batch ne suffit pas. Par exemple, dans la plupart des applications Batch, un compte de stockage Azure est requis. Le compte de stockage et le compte Batch doivent se trouver dans la même région pour des performances acceptables.

Lors de la conception d'une solution capable de basculer, tenez compte des points suivants :

  • Créez au préalable tous les services requis dans les différentes régions, comme le compte Batch et le compte de stockage. Il n’y a souvent aucun frais pour la création de comptes, et les frais s’accumulent uniquement lorsque le compte est utilisé ou lorsque des données sont stockées.

  • Assurez-vous à l’avance que les quotas appropriés sont définis pour tous les comptes Batch d’abonnement utilisateur , afin d’allouer le nombre requis de cœurs à l’aide du compte Batch.

  • Utilisez des modèles et/ou des scripts pour automatiser le déploiement de l'application dans une région.

  • Maintenez à jour les données de référence et les fichiers binaires des applications dans toutes les régions. Une région à jour pourra être mise en ligne rapidement sans avoir à attendre le téléchargement et le déploiement des fichiers. Par exemple, considérez le cas où une application personnalisée à installer sur des nœuds de pool est stockée et référencée à l’aide de packages d’application Batch. Lorsqu’une mise à jour de l’application est publiée, elle doit être chargée sur chaque compte Batch et référencée par la configuration du pool (ou faire de la dernière version la version par défaut).

  • Dans l’application qui appelle Batch, Stockage ou tout autre service, facilitez le basculement vers les clients ou la charge vers différentes régions.

  • Envisagez fréquemment de basculer vers une autre région dans le cadre d’un fonctionnement normal. Par exemple, avec deux déploiements dans des régions distinctes, basculez une fois par mois vers l’autre région.

La durée de récupération d’un sinistre dépend de la configuration que vous choisissez. Batch lui-même est indépendant de savoir si vous utilisez plusieurs comptes ou un seul compte. Dans les configurations actif-actif, où deux instances Batch reçoivent du trafic simultanément, la récupération d’urgence est plus rapide que pour une configuration active-passive. La configuration que vous choisissez doit être basée sur les besoins de l’entreprise (différentes régions, exigences de latence) et les considérations techniques.

Reprise d’activité dans une seule région

La façon dont vous implémentez la récupération d’urgence dans Batch est la même, que vous travailliez dans une zone géographique unique ou multi-région. Les seules différences sont la référence SKU que vous utilisez pour le stockage et si vous envisagez d’utiliser le même compte de stockage ou un compte de stockage différent dans toutes les régions.

Tests de récupération d'urgence

Vous devez effectuer vos propres tests de récupération d’urgence de votre solution batch activée. Il est considéré comme une bonne pratique pour permettre un basculement facile entre la charge du client et du service dans différentes régions.

Le test de votre plan de récupération d’urgence pour Batch peut être aussi simple que des comptes Batch alternatifs. Par exemple, vous pouvez vous appuyer sur un seul compte Batch dans une région spécifique pendant un jour opérationnel. Ensuite, le lendemain, vous pouvez basculer vers un deuxième compte Batch dans une autre région. La récupération d’urgence est principalement gérée côté client. Cette approche à plusieurs comptes de récupération d’urgence prend en charge les attentes en matière de RTO et de RPO dans des zones géographiques uniques ou à plusieurs régions.

Capacité et résilience proactive de la récupération d’urgence

Microsoft et ses clients opèrent sous le modèle de responsabilité partagée. Microsoft est responsable de la résilience des plateformes et des infrastructures. Vous êtes responsable de la récupération d’urgence pour tout service spécifique que vous déployez et contrôlez. Pour vous assurer que la récupération est proactive :

  • Vous devez toujours pré-déployer des fichiers secondaires. Le pré-déploiement des serveurs secondaires est nécessaire, car il n’existe aucune garantie de capacité au moment de l’impact pour ceux qui n’ont pas préalloué ces ressources.

  • Pré-créez tous les services requis dans chaque région, tels que vos comptes Batch et les comptes de stockage associés. Il n’y a aucun frais pour la création de comptes; les frais s’accumulent uniquement lorsque le compte est utilisé ou lorsque des données sont stockées.

  • Veillez à ce que des quotas appropriés soient définis à l’avance sur tous les abonnements afin de pouvoir allouer le nombre requis de cœurs à l’aide du compte Batch. Comme avec d’autres services Azure, il existe des limites concernant certaines ressources associées au service Batch. La plupart de ces limites représentent des quotas par défaut appliqués par Azure au niveau de l’abonnement ou du compte. Gardez ces quotas à l’esprit quand vous concevez et que vous augmentez vos charges de travail Batch.

Notes

Si vous envisagez d’exécuter des charges de travail de production dans Batch, vous devrez peut-être affecter à un ou plusieurs des quotas une valeur supérieure à la valeur par défaut. Pour augmenter un quota, vous pouvez demander une augmentation de quota gratuitement. Pour plus d’informations, consultez Demander une augmentation de quota.

Stockage

Vous devez configurer le stockage Batch pour vous assurer que les données sont sauvegardées entre les régions . la responsabilité du client est la valeur par défaut. La plupart des solutions Batch utilisent Stockage Azure pour stocker les fichiers de ressources et les fichiers de sortie. Par exemple, vos tâches Batch (y compris les tâches standard, de démarrage, de préparation des travaux et de validation des travaux) spécifient généralement des fichiers de ressources se trouvant dans un compte de stockage. Les comptes de stockage stockent également les données traitées et toutes les données de sortie générées. Il est important de comprendre les pertes de données possibles dans les régions de vos opérations de service. Vous devez également vérifier si les données sont réinscriptible ou en lecture seule.

Batch prend en charge les types de comptes Stockage Azure suivants :

  • Comptes Usage général v2 (GPv2)
  • Comptes Usage général v1 (GPv1)
  • Comptes de stockage d’objets blob (actuellement pris en charge pour les pools dans la configuration de la machine virtuelle)

Pour plus d’informations sur les comptes de stockage, consultez Vue d’ensemble des comptes de stockage Azure.

Vous pouvez associer un compte de stockage à votre compte Batch lorsque vous créez le compte. Vous avez également la possibilité de faire cette étape ultérieurement.

Si vous configurez un compte de stockage distinct pour chaque région dans laquelle votre service est disponible, vous devez utiliser des comptes de stockage redondant interzone (ZRS). Utilisez des comptes de stockage géo-redondant interzone (GZRS) si vous utilisez le même compte de stockage dans plusieurs régions jumelées. Pour les zones géographiques qui contiennent une seule région, vous devez créer un compte de stockage redondant interzone (ZRS), car GZRS n’est pas disponible.

La planification de la capacité est une autre considération importante avec le stockage et doit être traitée de manière proactive. Prenez en compte vos exigences en termes de coûts et de performances lorsque vous choisissez un compte de stockage. Par exemple, les options de compte de stockage Blob et GPv2 prennent en charge des limites d’extensibilité et de capacité plus importantes que celles des options GPv1. (Contactez le support technique Azure pour demander une augmentation de la limite de stockage.) Ces options de compte peuvent améliorer les performances des solutions Batch qui possèdent un certain nombre de tâches de lecture ou d’écriture s’exécutant simultanément sur le compte de stockage.

Lorsqu’un compte de stockage est lié à un compte batch, considérez le comme étant le compte auto-stockage. Un compte auto-stockage est nécessaire si vous envisagez d’utiliser la fonctionnalité packages d’application, car elle est utilisée pour stocker les fichiers .zip du package d’application. Un compte auto-stockage peut également être utilisée pour les fichiers de ressources de tâche; étant donné que le compte auto-stockage est déjà lié au compte batch, cela évite de devoir utiliser des URL de signature d’accès partagé (SAS) pour accéder aux fichiers de ressources.

Étapes suivantes