Partager via

Fiabilité dans Azure SQL Managed Instance

Azure SQL Managed Instance est un moteur de base de données PaaS (Platform as a Service). Il fournit près de 100% compatibilité des fonctionnalités avec SQL Server. Azure SQL Managed Instance gère la plupart des fonctions de gestion de base de données telles que la mise à niveau, la mise à jour corrective, les sauvegardes et la surveillance sans intervention de l’utilisateur. Il s’exécute sur la dernière version stable du moteur de base de données SQL Server et sur un système d’exploitation corrigé avec une haute disponibilité intégrée.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre Azure SQL Managed Instance résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il décrit également comment utiliser des sauvegardes pour récupérer à partir d’autres types de problèmes, comment gérer la maintenance du service et met en évidence certaines informations clés sur le contrat de niveau de service Azure SQL Managed Instance (SLA).

Recommandations de déploiement de production pour la fiabilité

Pour la plupart des déploiements de production de SQL Managed Instance, tenez compte des recommandations suivantes :

Vue d’ensemble de l’architecture de fiabilité

Les instances managées SQL à usage général s’exécutent sur un nœud unique géré par Azure Service Fabric . Chaque fois que le moteur de base de données ou le système d’exploitation est mis à niveau ou qu’un échec est détecté, SQL Managed Instance fonctionne avec Service Fabric pour déplacer le processus du moteur de base de données sans état vers un autre nœud de calcul sans état disposant d’une capacité suffisante. Les fichiers de base de données sont stockés dans Stockage Blob Azure, qui a des fonctionnalités de redondance intégrées. Les fichiers de données et de journaux sont détachés du nœud de calcul d’origine et attachés au processus du moteur de base de données nouvellement initialisé.

Les instances managées SQL critiques pour l’entreprise utilisent plusieurs réplicas dans un cluster. Le cluster inclut deux types de répliques :

  • Un réplica principal unique, accessible pour les charges de travail client en lecture et écriture

  • Jusqu’à cinq réplicas secondaires (calcul et stockage) qui contiennent des copies de données

Le réplica principal envoie constamment et séquentiellement des modifications aux réplicas secondaires, ce qui garantit que les données sont conservées sur un nombre suffisant de réplicas secondaires avant de valider chaque transaction. Ce processus garantit que si le réplica principal ou un réplica secondaire lisible deviennent indisponibles, un réplica entièrement synchronisé est toujours disponible pour un basculement.

SQL Managed Instance et Service Fabric initient un failover entre les réplicas. Une fois qu'une réplique secondaire devient la nouvelle réplique principale, une autre réplique secondaire est créée pour garantir que le cluster dispose d'un nombre suffisant de répliques pour maintenir le quorum. Une fois le basculement terminé, les connexions à Azure SQL sont automatiquement redirigées vers le nouveau réplica principal ou le réplica secondaire accessible en lecture, en fonction de la chaîne de caractères de connexion.

Redundancy

Par défaut, SQL Managed Instance obtient une redondance en répartissant les nœuds de calcul et les données dans un seul centre de données de la région primaire. Cette approche protège vos données pendant les temps d’arrêt attendus et inattendus suivants :

  • Opérations de gestion initiées par le client qui entraînent un bref temps d’arrêt

  • Opérations de maintenance de service

  • Pannes de réseau ou d’alimentation à petite échelle

  • Problèmes et pannes de centre de données qui impliquent les composants suivants :

    • Rack dans lequel les machines qui alimentent votre service sont opérationnelles.

    • Machine physique qui héberge la machine virtuelle exécutant le moteur de base de données SQL.

    • Machine virtuelle qui exécute le moteur de base de données SQL

  • Problèmes liés au moteur de base de données SQL

  • Pannes localisées potentielles non planifiées

Pour plus d’informations sur la façon dont SQL Managed Instance fournit une redondance, consultez Disponibilité via la redondance locale et interzone.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

SQL Managed Instance gère automatiquement les tâches de maintenance critiques, telles que la mise à jour corrective, les sauvegardes et les mises à niveau du moteur de base de données Windows et SQL. Il gère également les événements non planifiés tels que le matériel sous-jacent, les logiciels ou les défaillances réseau. SQL Managed Instance peut rapidement récupérer même dans les circonstances les plus critiques, ce qui garantit que vos données sont toujours disponibles. La plupart des utilisateurs ne remarquent pas que les mises à niveau sont effectuées en continu.

Lorsqu’une instance est corrigée ou bascule, le temps d’arrêt a un effet minimal si vous utilisez une logique de nouvelle tentative dans votre application. Vous pouvez tester la résilience de votre application en cas d’erreurs temporaires.

Résilience aux échecs de zone de disponibilité

Note

La redondance de zone n’est actuellement pas disponible pour le niveau de service Polyvalent nouvelle génération.

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Lorsque vous activez une configuration redondante interzone, vous pouvez garantir que votre instance managée SQL est résiliente face à un grand ensemble de défaillances, y compris les pannes catastrophiques du centre de données, sans aucune modification apportée à la logique de l’application.

SQL Managed Instance obtient une redondance de zone en plaçant des nœuds de calcul sans état dans différentes zones de disponibilité. Elle s’appuie sur un ZRS avec état attaché au nœud qui contient actuellement le processus actif du moteur de base de données SQL. Si une panne se produit, le processus du moteur de base de données SQL devient actif sur l’un des nœuds de calcul sans état, qui accède ensuite aux données dans le stockage avec état.

SQL Managed Instance obtient une redondance de zone en plaçant des réplicas de votre instance managée SQL sur plusieurs zones de disponibilité. Pour éliminer un point de défaillance unique, la boucle de contrôle est également dupliquée sur plusieurs zones. Le trafic du plan de contrôle est acheminé vers un équilibreur de charge qui est également déployé sur les zones de disponibilité. Azure Traffic Manager contrôle le routage du trafic du plan de contrôle vers l’équilibreur de charge.

Spécifications

  • Prise en charge de la région : La redondance de zone pour SQL Managed Instance est prise en charge dans certaines régions. Pour plus d’informations, consultez Régions prises en charge.

  • Redondance du stockage de sauvegarde : Pour activer la redondance de zone pour votre instance managée SQL, définissez la redondance du stockage de sauvegarde sur ZRS ou le stockage géoredondant interzone (GZRS).

Coûts

Lorsque vous activez la redondance de zone, il existe un coût supplémentaire pour votre instance managée SQL et pour les sauvegardes redondantes interzone. Pour plus d’informations, voir la tarification.

Vous pouvez économiser de l’argent en vous engageant à utiliser des ressources de calcul à un taux réduit pendant une période donnée, qui inclut des instances redondantes interzone dans le niveau de service Critique pour l’entreprise. Pour plus d’informations, consultez Réservations pour SQL Managed Instance.

Configurez la prise en charge des zones de disponibilité

Cette section explique comment configurer la prise en charge des zones de disponibilité pour vos instances managées SQL :

  • Activez la redondance de zone : Pour savoir comment configurer la redondance de zone sur les instances nouvelles et existantes, consultez Configurer la redondance de zone.

    Toutes les opérations de mise à l’échelle pour SQL Managed Instance, notamment l’activation de la redondance de zone, sont des opérations en ligne et nécessitent un temps d’arrêt minimal. Pour plus d’informations, consultez Durée des opérations de gestion.

  • Désactiver la redondance de zone : vous pouvez désactiver la redondance de zone en suivant les mêmes étapes que pour l’activer. Ce processus est une opération en ligne qui ressemble à une mise à niveau régulière de l’objectif des niveaux de service. À la fin du processus, l’instance est migrée de l’infrastructure redondante interzone vers une infrastructure à zone unique.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque votre instance managée SQL est configurée pour être redondante interzone et que toutes les zones de disponibilité sont opérationnelles :

  • Routage du trafic entre les zones : en fonctionnement normal, les requêtes sont acheminées vers le nœud qui exécute votre couche de calcul SQL Managed Instance.

  • Réplication des données entre les zones : Les fichiers de base de données sont stockés dans stockage Azure à l’aide de ZRS, qui est attaché à quel nœud contient actuellement le processus actif du moteur de base de données SQL.

    Les opérations d’écriture sont synchrones et ne sont pas considérées comme terminées tant que les données ne sont pas répliquées dans toutes les zones de disponibilité. Cette réplication synchrone garantit une cohérence forte et une perte de données nulle pendant les défaillances de zone. Toutefois, il peut entraîner une latence d’écriture légèrement plus élevée par rapport au stockage localement redondant.

  • Routage du trafic entre les zones : en fonctionnement normal, les requêtes sont routées vers le réplica principal de votre instance managée SQL.

  • Réplication des données entre les zones : le réplica principal envoie continuellement et séquentiellement des modifications aux réplicas secondaires dans différentes zones de disponibilité. Ce processus garantit que les données sont conservées sur un nombre suffisant de réplicas secondaires avant de valider chaque transaction. Ces réplicas se trouvent dans différentes zones de disponibilité. Ce processus garantit que, si le réplica principal ou un réplica secondaire lisible ne sont plus disponibles pour une raison quelconque, un réplica entièrement synchronisé est toujours disponible pour un basculement.

    Étant donné que les instances redondantes interzone ont des réplicas dans différents centres de données avec une certaine distance entre eux, la latence réseau accrue peut augmenter le temps de validation des transactions. Cette augmentation peut affecter les performances de certaines charges de travail OLTP (Online Transaction Processing). La plupart des applications ne sont pas sensibles à cette latence supplémentaire.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsque votre instance managée SQL est configurée pour être redondante interzone et qu’une ou plusieurs zones de disponibilité ne sont pas disponibles :

  • Détection et réponse : SQL Managed Instance est responsable de la détection et de la réponse à un échec dans une zone de disponibilité. Vous n’avez rien à faire pour initier un failover de zone.
  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle, et vous pouvez configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.
  • Demandes actives : lorsqu’une zone de disponibilité n’est pas disponible, toutes les requêtes en cours de traitement dans la zone de disponibilité défaillante sont arrêtées et doivent être retentées. Pour rendre vos applications résilientes à ces types de problèmes, consultez les conseils de résilience aux erreurs temporaires .

  • Réacheminement du trafic : SQL Managed Instance fonctionne avec Service Fabric pour déplacer le moteur de base de données vers un nœud de calcul sans état approprié qui se trouve dans une zone de disponibilité différente et dispose d’une capacité libre suffisante. Une fois le basculement terminé, les nouvelles connexions sont automatiquement redirigées vers le nouveau nœud de calcul principal.

    Une charge de travail importante peut rencontrer une dégradation des performances pendant la transition d’un nœud de calcul à l’autre nœud de calcul, car le nouveau processus du moteur de base de données commence par un cache froid.

  • Réacheminement du trafic : SQL Managed Instance fonctionne avec Service Fabric pour sélectionner un réplica approprié dans une autre zone de disponibilité, afin de lui permettre de devenir le réplica principal. Une fois qu'une réplique secondaire devient la nouvelle réplique principale, une autre réplique secondaire est créée pour garantir que le cluster dispose d'un nombre suffisant de répliques pour maintenir le quorum. Une fois le basculement terminé, de nouvelles connexions sont automatiquement redirigées vers la nouvelle réplique principale ou la réplique secondaire lisible, en fonction de la chaîne de connexion.

  • Temps d’arrêt attendu : il peut y avoir un petit temps d’arrêt pendant un basculement de zone de disponibilité. Le temps d’arrêt est généralement inférieur à 30 secondes, que votre application doit tolérer si elle suit les instructions de résilience aux erreurs temporaires .

  • Perte de données attendue : aucune perte de données n’est attendue pour les transactions validées pendant un basculement de zone de disponibilité. Les transactions en cours doivent être retentées.

Récupération de la zone

Lorsque la zone de disponibilité récupère, SQL Managed Instance fonctionne avec Service Fabric pour restaurer les opérations dans la zone récupérée. Aucune intervention du client n’est nécessaire.

Tester les pannes de zone

La plateforme SQL Managed Instance gère le routage du trafic, le basculement et le retour à la normale pour les instances redondantes interzone. Cette fonctionnalité étant complètement managée, vous n’avez pas besoin de lancer ou de valider les processus de défaillance de zone de disponibilité. Toutefois, vous pouvez valider la gestion des défaillances de votre application.

Résilience aux défaillances à l’échelle de la région

Une instance managée SQL individuelle est déployée dans une seule région. Toutefois, vous pouvez déployer une instance managée SQL secondaire dans une région Azure distincte et configurer un groupe de basculement.

Groupes de basculement

Les groupes de basculement géorépliquent automatiquement vos données et peuvent basculer automatiquement ou manuellement vos données en cas de défaillance régionale, en fonction de la stratégie de basculement.

Cette section récapitule les informations clés sur les groupes de basculement, mais il est important de passer en revue la vue d’ensemble des groupes de basculement et les meilleures pratiques pour en savoir plus sur leur fonctionnement et leur configuration.

Stratégies de basculement

Lorsque vous créez un groupe de basculement, vous sélectionnez la stratégie de basculement, qui spécifie qui est responsable de la détection d’une panne et de l’exécution d’un basculement. Vous pouvez configurer deux types de politiques de basculement :

  • Basculement géré par le client (recommandé) : Lorsque vous utilisez une stratégie de basculement gérée par le client, vous pouvez décider s’il faut effectuer un basculement, qui n’entraîne pas de perte de données ou un basculement forcé, ce qui peut entraîner une perte de données. Le basculement forcé est utilisé comme méthode de récupération pendant les pannes, lorsque l’instance principale n’est pas accessible.

  • Basculement géré par Microsoft : Le basculement géré par Microsoft est utilisé uniquement dans des situations exceptionnelles pour déclencher un basculement forcé.

Important

Utilisez les options de basculement managé par le client pour développer, tester et implémenter vos plans de récupération d’urgence. Ne comptez pas sur le basculement géré par Microsoft, car il n’est utilisé que dans des situations extrêmes. Un basculement managé par Microsoft est probablement lancé pour une région entière. Ils ne peuvent pas être lancés pour des groupes de basculement, des instances managées SQL, des abonnements ou des clients individuels. Le basculement peut se produire à différents moments pour différents services Azure. Nous vous recommandons d’utiliser le basculement managé par le client.

Soutien régional

Vous pouvez sélectionner n’importe quelle région Azure pour les instances managées SQL au sein du groupe de basculement. En raison de la latence élevée des réseaux étendus, la géoréplication utilise un mécanisme de réplication asynchrone. Pour réduire les retards réseau, sélectionnez les régions qui ont des connexions à faible latence. Pour plus d’informations sur la latence entre les régions Azure, consultez les statistiques de latence des allers-retours réseau Azure.

Coûts

Lorsque vous créez plusieurs instances managées SQL dans différentes régions, vous êtes facturé pour chaque instance managée SQL.

Toutefois, si votre instance secondaire n’a pas de charges de travail de lecture ni d’applications connectées, vous pouvez économiser sur les coûts de licence en désignant le réplica comme étant une instance de secours. Pour configurer cela, consultez Configurer un réplica de secours sans licence pour Azure SQL Managed Instance.

Pour plus d’informations sur la tarification de SQL Managed Instance, consultez les informations de tarification du service.

Configurer la prise en charge multirégion

Pour savoir comment configurer un groupe de basculement, consultez Configurer un groupe de basculement pour SQL Managed Instance.

Planification de capacité et gestion

Pendant un basculement, le trafic est redirigé vers une instance managée SQL secondaire. Il est important que votre instance managée SQL secondaire soit prête à recevoir le trafic. Créez une instance managée SQL secondaire avec le même niveau de service, la même génération de matériel et la même taille de calcul que l’instance principale.

Pour plus d’informations sur la mise à l’échelle des instances managées SQL dans un groupe de basculement, consultez Mettre à l’échelle des instances.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce qu’il faut attendre lorsque des instances managées SQL sont configurées pour utiliser des groupes de basculement multirégions et toutes les régions sont opérationnelles :

  • Routage du trafic entre les régions : en fonctionnement normal, les requêtes en lecture-écriture sont envoyées à l’instance principale unique dans la région principale.

    Les groupes de basculement fournissent également un point de terminaison d’écouteur en lecture seule distinct. En fonctionnement normal, ce point de terminaison se connecte à l’instance secondaire pour router le trafic en lecture seule spécifié dans la chaîne de connexion.

    Pour plus d’informations sur la façon dont les groupes de basculement envoient du trafic à chaque instance, et comment vous pouvez diriger le trafic vers un point de terminaison de lecteur en lecture seule, consultez Présentation et meilleures pratiques des groupes de basculement.

  • Réplication des données entre les régions : par défaut, les données sont répliquées de manière asynchrone depuis l’instance principale vers l’instance managée SQL secondaire.

    Étant donné que la géoréplication est asynchrone, si vous effectuez un basculement forcé, il est possible de subir une perte de données. Vous pouvez surveiller le décalage de réplication pour comprendre la perte de données potentielle pendant un basculement forcé. Pour plus d’informations, consultez la liste de contrôle d’urgence.

    Si vous devez éliminer la perte de données liée à la réplication asynchrone lors des basculements, configurez votre application pour bloquer le thread appelant jusqu’à ce qu’elle confirme que la dernière transaction validée a été transmise et inscrite de manière permanente dans le journal des transactions de la base de données secondaire. Cette approche nécessite un développement personnalisé et dégrade les performances de votre application. Pour plus d’informations, consultez Empêcher la perte de données critiques.

Comportement lors d’une défaillance de région

Cette section décrit ce qu’il faut attendre lorsque les instances managées SQL sont configurées pour utiliser des groupes de basculement multirégions et qu’il existe une panne dans la région primaire :

  • Détection et réponse : la responsabilité de la détection et de la réponse dépend de la stratégie de basculement utilisée par votre groupe de basculement.

    • Stratégie de basculement managée par le client : vous êtes responsable de la détection de la défaillance dans une région et du déclenchement d’un basculement ou d’un basculement forcé vers l’instance secondaire dans le groupe de basculement.

      Si vous effectuez un basculement, SQL Managed Instance attend que les données se synchronisent avec l’instance secondaire avant d’effectuer la procédure de basculement.

      Si vous effectuez un basculement forcé, SQL Managed Instance bascule immédiatement l’instance secondaire vers le rôle principal sans attendre que les modifications récentes se propagent à partir du serveur principal. Ce type de basculement peut entraîner une perte de données.

    • Stratégie de basculement managée par Microsoft : les basculements managés par Microsoft sont effectués dans des circonstances exceptionnelles. Lorsque Microsoft déclenche un basculement, le groupe de basculement effectue automatiquement un basculement forcé vers l’instance secondaire dans le groupe de basculement. Toutefois, nous vous recommandons d’utiliser une stratégie de basculement gérée par le client pour les charges de travail de production afin de pouvoir contrôler le moment où le basculement se produit.

  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle, et vous pouvez configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

  • Demandes actives : Lorsqu’un basculement se produit, toutes les requêtes en cours de traitement sont interrompues et doivent être retentées. Pour rendre vos applications résilientes à ces types de problèmes, consultez Résilience aux erreurs temporaires.

  • Perte de données attendue : La quantité de perte de données dépend de la façon dont vous configurez votre application. Pour plus d’informations, voir aperçu des groupes de basculement et meilleures pratiques.

  • Temps d’arrêt attendu : il peut y avoir un petit temps d’arrêt pendant le basculement d’un groupe de basculement. Le temps d’arrêt est généralement inférieur à 60 secondes.

  • Réacheminement du trafic : Une fois le groupe de basculement terminé le processus de basculement, le trafic en lecture-écriture est routé automatiquement vers la nouvelle instance principale. Si vos applications utilisent les points de terminaison du groupe de basculement dans leurs chaînes de connexion, elles n’ont pas besoin de modifier leurs chaînes de connexion après le basculement.

Récupération de région

Les groupes de basculement ne basculent pas automatiquement vers la région principale lorsqu’ils sont restaurés, et il vous incombe donc de lancer une restauration automatique.

Tester les défaillances régionales

Vous pouvez tester le basculement d’un groupe de basculement.

Le test d’un groupe de basculement n’est qu’une partie de la réalisation d’un exercice de récupération d'urgence. Pour plus d’informations, consultez Effectuer des exercices de DR.

Sauvegarde et restauration

Effectuez des sauvegardes de vos bases de données pour vous protéger contre différents risques, notamment la perte de données. Les sauvegardes peuvent être restaurées pour récupérer à partir d’une perte de données accidentelle, d’une altération ou d’autres problèmes. Les sauvegardes ne sont pas identiques à la géoréplication, et elles ont des objectifs différents et atténuent les différents risques.

SQL Managed Instance prend automatiquement des sauvegardes complètes, différentielles et de journal des transactions de vos bases de données. Pour plus d’informations sur les types de sauvegardes, leur fréquence, leurs fonctionnalités de restauration, les coûts de stockage et le chiffrement de sauvegarde, consultez sauvegardes automatisées dans SQL Managed Instance.

SQL Managed Instance fournit des sauvegardes automatisées intégrées et prend également en charge les sauvegardes de copie lancées par l’utilisateur uniquement pour les bases de données utilisateur. Pour plus d’informations, consultez Sauvegardes de type copie seule.

Réplication de sauvegarde

Lorsque vous configurez des sauvegardes automatisées pour votre instance managée SQL, vous pouvez spécifier la façon dont les sauvegardes doivent être répliquées. Les sauvegardes configurées pour être stockées sur ZRS ont un niveau de résilience plus élevé. Nous vous recommandons de configurer vos sauvegardes pour utiliser l’un des types de stockage suivants :

  • ZRS pour la résilience au sein de la région, si la région a des zones de disponibilité

  • GZRS pour améliorer la résilience de vos sauvegardes entre les régions si la région a des zones de disponibilité et est jumelée à une autre région

  • GRS si votre région ne prend pas en charge les zones de disponibilité, mais a une région jumelée

Pour plus d’informations sur les différents types de stockage et leurs fonctionnalités, consultez Redondance du stockage de sauvegarde.

Géorestauration

La fonctionnalité de géorestauration est une solution de récupération d’urgence de base qui vous permet de restaurer des copies de sauvegarde dans une autre région Azure. La géo-sauvegarde nécessite généralement un temps d’arrêt et une perte de données importants. Pour atteindre des niveaux plus élevés de récupération si une interruption régionale se produit, vous devez configurer des groupes de basculement.

Si vous utilisez la géorestauration, vous devez envisager comment rendre vos sauvegardes disponibles dans votre région secondaire :

  • Si votre région principale est jumelée, utilisez le stockage de sauvegarde GZRS ou GRS pour prendre en charge la géorestauration dans la région jumelée.

  • Si votre région principale n’est pas jumelée, vous pouvez créer une solution personnalisée pour répliquer vos sauvegardes vers une autre région. Envisagez d’utiliser des sauvegardes de type copie seule initiées par l’utilisateur et de les stocker dans un compte de stockage qui utilise la réplication d’objet blob pour répliquer sur un compte de stockage dans une autre région.

Résilience à la maintenance du service

Lorsque SQL Managed Instance effectue une maintenance sur votre instance, l’instance managée SQL reste entièrement disponible, mais peut être soumise à de courtes reconfigurations. Les applications clientes peuvent observer de brèves interruptions de connectivité lorsqu’un événement de maintenance se produit. Vos applications clientes doivent suivre les instructions de résilience aux erreurs temporaires pour réduire les effets.

SQL Managed Instance vous permet de spécifier une fenêtre de maintenance généralement utilisée pour les mises à niveau de service et d’autres opérations de maintenance. La configuration d’une fenêtre de maintenance peut vous aider à réduire les effets secondaires, tels que les basculements automatiques, pendant vos heures de travail. Vous pouvez également recevoir une notification préalable de maintenance planifiée.

Pour plus d’informations, consultez la fenêtre Maintenance dans SQL Managed Instance.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Pour SQL Managed Instance, le contrat SLA de disponibilité s’applique uniquement lorsque votre réseau virtuel Azure est correctement configuré afin qu’il n’entrave pas le trafic de gestion. Cette configuration inclut la taille du sous-réseau, les groupes de sécurité réseau (NSG), les itinéraires définis par l’utilisateur (UDR), la configuration DNS et d’autres ressources qui affectent la gestion et l’utilisation des ressources réseau. Pour plus d’informations sur la configuration réseau requise pour SQL Managed Instance, consultez configuration réseau requise.

Contenu connexe

  • Last updated on