<properties
   pageTitle="Liste de vérification de disponibilité | Microsoft Azure"
   description="Une liste rapide des paramètres et les actions que vous pouvez prendre pour vous assurer sont amélioration de la disponibilité de vos applications Azure."
   services=""
   documentationCenter="na"
   authors="adamglick"
   manager="saladki"
   editor=""/>
<tags
   ms.service="resiliency"
   ms.devlang="na"
   ms.topic="article"
   ms.tgt_pltfrm="na"
   ms.workload="na"
   ms.date="08/18/2016"
   ms.author="aglick"/>
#<a name="high-availability-checklist"></a>Liste de contrôle de haute disponibilité
Un des principaux avantages de l’utilisation d’Azure est la possibilité d’accroître la disponibilité (et l’évolutivité) de vos applications à l’aide du nuage. Pour vous assurer que vous effectuez la plupart de ces options, la liste de contrôle ci-dessous est destiné pour vous aider à certains aspects de l’infrastructure à clé pour s’assurer que vos applications sont résilientes. 
>[AZURE.NOTE] La plupart de ces suggestions ci-dessous, voici ce qui peut être implémentée à tout moment dans votre application et sont parfaits pour « correctifs à chaud ». La solution optimale à long terme implique souvent une conception d’application qui est conçue pour le cloud.  Pour un aide-mémoire sur ces (plus conception orientée de zones, veuillez lire notre [liste de vérification de disponibilité](../best-practices-availability-checklist.md).
###<a name="are-you-using-traffic-manager-in-front-of-your-resources"></a>Vous utilisez le Gestionnaire de trafic devant vos ressources ?
À l’aide de trafic Manager vous aide à vous routez le trafic internet sur Azure régions ou emplacements Azure et sur site. Vous pouvez cela pour un certain nombre de raisons, notamment les temps de latence et de disponibilité. Si vous souhaitez obtenir des informations supplémentaires sur l’utilisation du Gestionnaire de trafic pour accroître votre souplesse et répartir le trafic dans plusieurs régions, lecture [En cours d’exécution pour ordinateurs virtuels dans des centres de données multiples sur Azure pour une haute disponibilité](../guidance/guidance-compute-multiple-datacenters.md).
__Que se passe-t-il si vous n’utilisez pas le Gestionnaire de trafic ?__ Si vous n’utilisez pas le Gestionnaire de trafic devant votre application, vous êtes limité à une seule région pour vos ressources. Cela limite votre échelle augmente la latence pour les utilisateurs qui ne sont pas près de votre région choisie et réduit votre protection en cas de rupture de service à l’échelle de la région.
###<a name="have-you-avoided-using-a-single-virtual-machine-for-any-role"></a>Vous être évitées à l’aide d’une seule machine virtuelle pour n’importe quel rôle ?
Une bonne conception permet d’éviter tout point de défaillance unique. Cela est important dans la conception de tous les services (sur site ou dans le nuage) mais est particulièrement utile dans le nuage, que vous pouvez augmenter l’évolutivité et la résilience bien évolution horizontale (ajout de machines virtuelles) au lieu de la mise à l’échelle (à l’aide d’une machine virtuelle plus puissante). Si vous souhaitez en trouver plus d’informations sur la conception d’applications évolutives, lisez la [haute disponibilité des applications basées sur Microsoft Azure](resiliency-high-availability-azure-applications.md).
__Que se passe-t-il si vous disposez d’une seule machine virtuelle pour un rôle ?__ Une seule machine est un point de défaillance unique et n’est pas disponible pour l' [Accord de niveau de Service de Machine virtuelle Azure](https://azure.microsoft.com/support/legal/sla/virtual-machines/v1_0/). Dans les meilleurs cas, votre application s’exécutera parfaitement, mais cela n’est pas une conception robuste, ne relèvent pas du SLA de Machine virtuelle Azure et tout point unique d’augmente de défaillance le risque de temps d’arrêt si un élément échoue.
###<a name="are-you-using-a-load-balancer-in-front-of-your-applications-internet-facing-vms"></a>Si vous utilisez un équilibreur de charge devant les ordinateurs virtuels de votre application avec accès via internet ?
Équilibreurs de charge permettent de répartir le trafic entrant à votre application un nombre quelconque d’ordinateurs. Vous pouvez ajouter/supprimer machines de votre équilibreur de charge à tout moment, ce qui fonctionne bien avec les Machines virtuelles (et auto-mise à l’échelle avec des jeux d’échelle de Machine virtuelle) vous permet de gérer facilement les augmentations de trafic ou des défaillances de l’ordinateur virtuel. Si vous souhaitez en savoir plus sur les équilibreurs de charge, consultez la [vue d’ensemble de l’équilibrage de charge Azure](../load-balancer/load-balancer-overview.md) et [l’exécution de plusieurs ordinateurs virtuels sur Azure pour l’évolutivité et la disponibilité](../guidance/guidance-compute-multi-vm.md).
__Que se passe-t-il si vous n’utilisez pas un équilibreur de charge devant vos ordinateurs virtuels du côté internet ?__ Sans un équilibreur de charge, vous ne serez pas en mesure de faire évoluer (ajouter plus de machines virtuelles) et votre seule option sera mise à l’échelle (augmenter la taille de votre machine virtuelle d’orientée web). Vous devrez également un point unique de défaillance avec cet ordinateur virtuel. Vous devez également écrire du code DNS pour Notez si vous avez perdu une machine faisant face à internet et mappez de nouveau votre entrée DNS sur le nouvel ordinateur que vous commencez à prendre sa place.
###<a name="are-you-using-availability-sets-for-your-stateless-application-and-web-servers"></a>Sont automatiquement à l’aide de la disponibilité des jeux pour vos serveurs web et les applications sans état ?
Placer vos machines dans le même niveau de l’application dans un jeu de disponibilité autorise vos ordinateurs virtuels pour les SLA de VM Azure. Faisant partie d’une disponibilité à définir également garantit que vos ordinateurs sont placés dans des domaines différents de mise à jour (c'est-à-dire les machines de hôte différent sont corrigés à des moments différents) et fault domaines (c'est-à-dire les ordinateurs hôtes qui partagent un réseau et une source d’alimentation commune commutateur). Sans être dans un jeu de disponibilité, vos ordinateurs virtuels peuvent se trouver sur le même ordinateur hôte, et par conséquent, il peut y avoir un point unique de défaillance qui n’est pas visible pour vous. Si vous souhaitez en trouver plus d’informations sur l’augmentation de la disponibilité de vos machines virtuelles à l’aide de jeux de disponibilité, consultez [Gérer la disponibilité des ordinateurs virtuels](../virtual-machines/virtual-machines-windows-manage-availability.md).
__Que se passe-t-il si vous n’utilisez pas une disponibilité avec vos applications sans état et les serveurs web ?__ N’utilisez ne pas une disponibilité définie signifie que vous n’êtes pas en mesure de tirer parti de la machine virtuelle de Azure accords SLA. Cela signifie également que machines dans cette couche de votre application pourraient tous hors connexion s’il existe une mise à jour sur l’ordinateur hôte (l’ordinateur qui héberge les ordinateurs virtuels que vous utilisez), ou une défaillance matérielle commune.
###<a name="are-you-using-virtual-machine-scale-sets-vmss-for-your-stateless-application-or-web-servers"></a>Utilisez-vous des jeux d’échelle d’ordinateur virtuel (VMSS) pour vos serveurs web ou des application sans état ?
Une bonne conception évolutive et utilise VMSS pour vous assurer que vous pouvez agrandir/réduire le nombre d’ordinateurs dans une couche de votre application (par exemple, votre niveau web). VMSS vous permet de définir comment votre couche application met à l’échelle (ajout ou suppression de serveurs en fonction de critères que vous choisissez). Si vous souhaitez obtenir des informations supplémentaires sur l’utilisation des jeux d’échelle Azure Virtual Machine pour augmenter votre tolérance aux pics de trafic, lisez la [Vue d’ensemble des jeux d’ordinateur virtuel échelle](../virtual-machine-scale-sets/virtual-machine-scale-sets-overview.md).
__Que se passe-t-il si vous ne nous une échelle de Machine virtuelle définie avec mon application sans état du serveur web ?__ Sans une VMSS, vous limitez votre capacité à mettre à l’échelle sans limite et pour optimiser l’utilisation des ressources. Un design qui n’a pas de VMSS a une limite de mise à l’échelle qui devront être gérées avec code supplémentaire (ou manuellement). Ce manque d’un VMSS signifie également que votre application ne peut pas facilement ajouter et supprimer des ordinateurs (quel que soit l’échelle) pour vous aider à gérer les importants pics de trafic (ces au cours d’une promotion ou si votre site/application/produit passe virale).
###<a name="are-you-using-premium-storage-and-separate-storage-accounts-for-each-of-your-virtual-machines"></a>Vous utilisez le stockage de la prime et les comptes de stockage distincte pour chacune de vos machines virtuelles ?
Il est recommandé d’utiliser le stockage de la prime pour vos machines virtuelles de production. En outre, vous devez vous assurer que vous utilisez un compte de stockage distincte pour chaque machine virtuelle (cela est vrai pour les déploiements à petite échelle. Pour les déploiements plus importants, vous pouvez l’utiliser pour plusieurs machines mais il existe des comptes de stockage est un équilibrage qui doit être effectuée pour vérifier que vous sont équilibrées sur les domaines de mise à jour et les couches de votre application). Si vous souhaitez obtenir des informations supplémentaires sur l’évolutivité et les performances de stockage Azure, lire [Microsoft Azure Storage Performance et l’évolutivité de liste de contrôle](../storage/storage-performance-checklist.md).
__Que se passe-t-il si vous n’utilisez pas les comptes de stockage distinct pour chaque ordinateur virtuel ?__ Un compte de stockage, comme beaucoup d’autres ressources est un point de défaillance unique. Bien qu’il existe de nombreuses protections et des fonctions de résistance de stockage Azure, un point de défaillance unique n’est jamais une bonne conception. Par exemple, si les droits d’accès obtenir endommagés à ce compte, une limite de stockage est atteinte ou une [limitent d’e/s](../azure-subscription-service-limits.md#virtual-machine-disk-limits) est atteinte, tous les ordinateurs virtuels à l’aide de ce compte de stockage sont concernés. En outre, s’il y a une interruption de service qui a une incidence sur un tampon de stockage contenant ce compte de stockage particulier, vous pouvez avoir plusieurs ordinateurs virtuels sont affectés.
###<a name="are-you-using-a-load-balancer-or-a-queue-between-each-tier-of-your-application"></a>Si vous utilisez un équilibreur de charge ou d’une file d’attente entre chaque couche de votre application ?
Équilibreurs de charge ou de files d’attente entre chaque couche de votre application vous permet d’évoluer de manière unique chaque couche de votre application facilement et de façon indépendante. Vous devez choisir entre ces technologies en fonction de votre temps de latence, la complexité, et a besoin de distribution (c'est-à-dire comment largement vous distribuez votre application). En général, les files d’attente ont tendance à avoir une latence plus élevée et ajouter de la complexité, mais avantages à être plus résistants et qui vous permet de distribuer votre application sur des zones plus vastes (tels que dans les régions). Si vous souhaitez obtenir des informations supplémentaires sur la façon d’utiliser des équilibreurs de charge interne ou des files d’attente, veuillez lire [l’équilibreur de charge interne vue d’ensemble](../load-balancer/load-balancer-internal-overview.md) et des [files d’attente files d’attente Azure et Bus de Service - comparées et contrairement](../service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted.md).
__Que se passe-t-il si vous n’utilisez pas un équilibreur de charge ou de la file d’attente entre chaque couche de votre application ?__ Sans un équilibreur de charge ou de file d’attente, entre chaque couche de votre application il est difficile de faire évoluer votre application vers le haut ou vers le bas et de distribuer la charge sur plusieurs ordinateurs. Ne pas le faire peut entraîner sur ou sous la mise en service de vos ressources et un risque de temps d’arrêt ou de l’expérience utilisateur médiocre, si vous avez des modifications inattendues dans les défaillances du trafic ou du système.
 
###<a name="are-your-sql-databases-using-active-geo-replication"></a>Vos bases de données SQL utilisent géo-réplication active ? 
Geo-réplication Active vous permet de configurer jusqu'à 4 bases de données secondaires lisibles dans les régions identiques ou différentes. Bases de données secondaires sont disponibles dans le cas d’une interruption de service ou de l’incapacité à se connecter à la base de données principale. Si vous souhaitez en savoir plus sur géo-réplication active de la base de données SQL, reportez-vous à [vue d’ensemble : SQL de base de données géo-réplication Active](../sql-database/sql-database-geo-replication-overview.md).
 
 __Que se passe-t-il si vous n’utilisez pas géo-réplication active avec vos bases de données SQL ?__ Sans géo-réplication active, si votre base de données principal est hors connexion (maintenance planifiée, interruption de service, panne matérielle, etc.) votre base de données de l’application sera hors connexion jusqu'à ce que vous pouvez importer votre base de données principale en ligne dans un état sain. 
 
###<a name="are-you-using-a-cache-azure-redis-cache-in-front-of-your-databases"></a>Vous utilisez un cache (Azure Redis Cache) en regard de vos bases de données ?
Si votre application a une charge élevée de la base de données où la plupart des appels de base de données est des lectures, vous pouvez augmenter la vitesse de votre application et réduire la charge sur votre base de données en implémentant une couche de mise en cache devant votre base de données pour ces opérations de lecture de déchargement. Vous pouvez augmenter la vitesse de votre application et réduire votre charge de base de données (ce qui augmente l’échelle qu’il peut gérer) en plaçant une couche de mise en cache devant votre base de données. Si vous souhaitez en savoir plus sur le cache Azure Redis, veuillez lire le [Guide de mise en cache](../best-practices-caching.md).
 
 __Que se passe-t-il si vous n’utilisez pas un cache devant votre base de données ?__ Si votre ordinateur de la base de données est suffisamment puissant pour gérer la charge de trafic vous placez dessus puis votre application répond comme d’habitude, même si cela peut signifier qu’à faible charge vous paierez pour un ordinateur de base de données qui est plus coûteux que nécessaire. Si votre ordinateur de la base de données n’est pas puissant pour gérer votre charge puis vous commencerez à l’expérience utilisateur médiocre rencontrer avec votre application (latence, délais d’attente et éventuellement des interruptions de service).
 
###<a name="have-you-contacted-microsoft-azure-support-if-you-are-expecting-a-high-scale-event"></a>Avez-vous contacté le support technique de Microsoft Azure si vous attendez un événement de grande échelle ?
Prise en charge Azure peut vous aider à augmenter vos limites de service pour traiter les événements planifiés de trafic élevé (comme le lancement de nouveaux produits ou des jours fériés spéciaux). Prise en charge Azure peut-être également vous aider à communiquer avec des experts qui peut vous aider à Vérifiez votre conception avec votre équipe de compte et vous aider à trouver la meilleure solution pour répondre aux besoins d’événement de grande échelle. Si vous souhaitez obtenir des informations supplémentaires sur la façon de contacter le support technique Azure, veuillez lire la [FAQ de prise en charge d’Azure](https://azure.microsoft.com/support/faq/).
__Que se passe-t-il si vous ne contactez le support technique de Azure pour un événement de grande échelle ?__ Si vous ne communiquer ou prévoir, un événement de trafic élevé, vous risquez d’appuyant sur certains [services Azure limite](../azure-subscription-service-limits.md) et créer ainsi une expérience utilisateur médiocre (ou pire, temps d’arrêt) au cours de votre événement. Révision architecturale et communique en avance sur les pics peuvent aider à limiter ces risques.
###<a name="are-you-using-a-content-delivery-network-azure-cdn-in-front-of-your-web-facing-storage-blobs-and-static-assets"></a>Vous utilisez un réseau de livraison de contenu (CDN Azure) devant votre BLOB de stockage orientés vers le web et les éléments statiques
À l’aide d’un CDN vous aide à prendre charge vos serveurs par la mise en cache de votre contenu dans les emplacements CDN POP/edge qui se trouvent dans le monde entier. Vous pouvez le faire pour réduire la latence, augmenter l’évolutivité, diminuer la charge du serveur et comme partie intégrante d’une stratégie de protection contre le déni de service (DOS) attaques. Si vous souhaitez obtenir des informations supplémentaires sur l’utilisation d’Azure CDN pour accroître votre souplesse et diminuer la latence de votre client, lisez la [Présentation de l’Azure réseau CDN (Content Delivery)](../cdn/cdn-overview.md).
__Que se passe-t-il si vous n’utilisez pas un réseau CDN ?__ Si vous n’utilisez pas un réseau CDN tout votre trafic client provient directement à vos ressources. Cela signifie que vous ne verrez des charges plus élevées sur les serveurs qui réduit leur évolutivité. En outre, vos clients peuvent être confrontés les latences supérieures CDN proposer des emplacements qui sont susceptibles de plus près à vos clients dans le monde entier.
##<a name="next-steps"></a>Étapes suivantes :
Si vous souhaitez lire plus d’informations sur la conception de vos applications pour une haute disponibilité, veuillez lire à [haute disponibilité pour les applications basées sur Microsoft Azure](resiliency-high-availability-azure-applications.md).