Continuité d’activité et reprise d’activité pour SQL Managed Instance avec Azure Arc

SQL Managed Instance avec Azure Arc offre des fonctionnalités de continuité d’activité et reprise d’activité (BCDR) qui aident les entreprises à récupérer suite aux interruptions et à continuer à opérer avec un temps d’arrêt minimal.

Cet article fournit des considérations et recommandations de conception clés pour la configuration et la gestion des fonctionnalités de continuité d’activité, telles que la restauration à un point dans le temps, la haute disponibilité et la reprise d’activité après sinistre.

Architecture

Les diagrammes d’architecture suivants montrent les fonctionnalités de haute disponibilité de SQL Managed Instance avec Arc dans le niveau de service Critique pour l’entreprise, qui prend en charge le basculement avec un temps d’arrêt quasi nul. Si l’instance principale échoue, l’équilibreur de charge cesse d’envoyer du trafic à cette instance. Ensuite, l’une des instances secondaires est promue en instance principale, et cette instance commence à recevoir le trafic en lecture-écriture en provenance de l’équilibreur de charge. Une fois que l’instance ayant échoué est revenue en ligne, elle est ajoutée en tant qu’instance secondaire.

Le diagramme d’architecture suivant montre comment SQL Managed Instance avec Arc peut être déployé sur deux clusters Kubernetes distincts dans deux sites différents à des fins de reprise d’activité.

Le diagramme d’architecture suivant montre comment SQL Managed Instance avec Arc répond lorsqu’un basculement de reprise d’activité est lancé.

Remarques relatives à la conception

Pour évaluer l’effet de SQL Managed Instance avec Azure Arc sur votre modèle BCDR global, passez en revue les recommandations BCDR pour les zones d’atterrissage fournies dans Continuité d’activité et reprise d’activité. Notez que le contenu de Continuité d’activité et reprise d’activité est axé uniquement sur les recommandations de conception pour la continuité d’activité, mais que la haute disponibilité et la résilience de votre instance dépendent également de la disponibilité de l’infrastructure Kubernetes sous-jacente.

Restauration dans le temps

• Définissez vos cibles d’objectif de point de récupération (RPO) et d’objectif de délai de récupération (RTO).

• Déterminez la durée pendant laquelle vous souhaitez conserver et restaurer vos sauvegardes dans les limites de rétention prises en charge.

• Tenez compte des implications en terme de stockage et du coût de l’augmentation de la durée de rétention de vos sauvegardes. La durée de rétention par défaut est de sept jours. Avec cette durée, vous pouvez restaurer jusqu’à sept jours, et obtenir une sauvegarde complète, une sauvegarde différentielle quotidienne et des sauvegardes des journaux transactionnels environ toutes les cinq minutes.

• Réfléchissez à la classe de stockage à utiliser pour le volume persistant pour les sauvegardes. Pour obtenir des conseils, consultez Disciplines de stockage pour SQL Managed Instance avec Azure Arc.

• Réfléchissez à la taille du volume persistant pour les sauvegardes dans le contexte de la taille de données attendue et de la durée de rétention configurée.

• Pour connaître les bonnes pratiques en matière de stockage, consultez Disciplines de stockage pour SQL Managed Instance avec Azure Arc.

• Les sauvegardes sont toujours effectuées sur le réplica principal. Tenez compte des effets sur les performances des processus de sauvegarde et de restauration lors de l’identification des ressources allouées à votre instance.

• N’oubliez pas que les restaurations à un instant dans le passé d’une base de données ne peuvent pas remplacer une base de données existante. En revanche, elles peuvent restaurer des données dans une nouvelle base de données sur la même instance.

• Tenez compte des étapes supplémentaires nécessaires pour récupérer entièrement votre base de données si votre application est en ligne pendant le processus de restauration.

• Tenez compte des étapes supplémentaires requises pour restaurer une base de données sur une instance à plusieurs réplicas, comme décrit dans Restauration d’une base de données sur une instance à plusieurs réplicas.

• Déterminez les outils utilisés par les administrateurs de base de données pour configurer et restaurer des sauvegardes. Pour plus d’informations, consultez Se connecter à SQL Managed Instance avec Azure Arc.

Haute disponibilité

• Passez en revue les exigences de disponibilité de votre charge de travail, et choisissez le niveau de service le mieux adapté à votre déploiement de SQL Managed Instance avec Arc :

  • Au niveau de service Usage général, un seul réplica est disponible, et la haute disponibilité est obtenue via l’orchestration Kubernetes.
  • Au niveau de service Critique pour l’entreprise, SQL Managed Instance avec Azure Arc fournit un groupe de disponibilité autonome, en plus de ce qui est fourni en mode natif par l’orchestration Kubernetes.

• Prenez en compte les effets potentiels du temps d’arrêt dans le niveau de service Usage général dû à l’existence d’un seul réplica.

• Réfléchissez au nombre de réplicas (de un à trois) à déployer dans le niveau de service Critique pour l’entreprise.

• Lors du déploiement d’une instance dans un niveau de service Critique pour l’entreprise avec plusieurs réplicas, vous pouvez configurer les réplicas secondaires comme lisibles. Déterminez le nombre de réplicas secondaires à déployer dans le niveau de service Critique pour l’entreprise. Pour plus d’informations sur la modification du nombre, consultez Configurer des réplicas secondaires lisibles.

• Décidez si vous souhaitez privilégier la cohérence par rapport à la disponibilité via le nombre de réplicas secondaires requis pour valider une transaction dans le niveau de service Critique pour l’entreprise à l’aide du paramètre facultatif--sync-secondary-to-commit. S’il existe des problèmes de connectivité entre les réplicas, le réplica principal risque de ne valider aucune transaction :

  • Dans une configuration à deux réplicas, une transaction doit être validée sur les deux réplicas pour que le réplica principal reçoive un message de réussite.
  • Dans une configuration à trois réplicas, au moins deux des trois réplicas doivent valider une transaction pour retourner un message de réussite.

• Déterminez si vous devez désigner un réplica spécifique comme réplica principal. Pour plus d’informations sur la spécification d’un réplica principal, consultez Réplica principal préféré.

• Déterminez le type de service Kubernetes que vous utiliserez, LoadBalancer ou NodePort. Si vous utilisez l’équilibreur de charge, les applications peuvent se reconnecter au même point de terminaison principal, et Kubernetes redirigera la connexion vers le nouveau réplica principal. Si vous utilisez le port de nœud, les applications doivent se reconnecter à la nouvelle adresse IP.

Récupération d'urgence

• Les instances de SQL Managed Instance avec Azure Arc dans les sites géoprincipaux et géosecondaires doivent être identiques en termes de capacité et de calcul, et elles doivent être déployées dans les mêmes niveaux de service.

• Choisissez un emplacement dans lequel stocker les certificats de mise en miroir lorsque vous créez la configuration de reprise d’activité accessible par les deux clusters qui hébergent l’instance.

• Réfléchissez à la façon de superviser le temps d’arrêt de l’instance principale, afin de décider quand effectuer un basculement vers l’instance secondaire.

• Chaque instance a ses propres points de terminaison. Réfléchissez à la façon dont vos applications accéderont au point de terminaison principal avec une interruption minimale en cas de basculement.

Recommandations de conception

Les sections suivantes listent les recommandations de conception pour la restauration à un instant dans le passé, la haute disponibilité et la reprise d’activité.

Restauration dans le temps

• Lors du déploiement d’une nouvelle instance de SQL Managed Instance avec Arc, définissez toujours la classe de stockage pour les sauvegardes afin d’éviter d’utiliser par défaut la classe de stockage de données.

• Utilisez une classe de stockage qui prend en charge ReadWriteMany (RWX) pour le volume de sauvegardes. Pour obtenir des conseils, consultez Disciplines de stockage pour SQL Managed Instance avec Azure Arc.

• Avant de démarrer une opération de restauration, utilisez le paramètre facultatif--dry-run pour vérifier d’abord si l’opération réussirait. Pour plus d’informations, consultez Créer une base de données à partir d’un point dans le temps à l’aide d’az CLI.

• Créez un processus pour envoyer des sauvegardes nécessitant des durées de rétention plus longues vers Azure ou un autre stockage froid local.

• Supervisez le stockage consommé par vos sauvegardes afin de déterminer si vous pouvez prendre en charge une rétention plus longue, si nécessaire.

Haute disponibilité

• Effectuez des exercices réguliers afin de valider la haute disponibilité de votre instance de SQL Managed Instance avec Arc. Ces exercices peuvent par exemple inclure la suppression d’un pod dans une instance Usage général et la défaillance d’un réplica dans une instance Critique pour l’entreprise.

• Au niveau Critique pour l’entreprise, déployez une instance dans une configuration à trois réplicas au lieu d’une configuration à deux réplicas pour obtenir une perte de données quasi nulle.

• Pour une meilleure disponibilité, utilisez LoadBalancer comme type de service lors du déploiement d’une instance.

• Passez en revue les limitations de haute disponibilité de SQL Managed Instance avec Azure Arc.

• Passez en revue les modes de disponibilité pris en charge pour déterminer le mode à utiliser en fonction de vos besoins en haute disponibilité.

• Lors du déploiement d’une instance Critique pour l’entreprise avec plusieurs réplicas, utilisez l’un des réplicas secondaires pour les charges de travail de lecture. Votre chaîne de connexion d’application doit spécifier le point de terminaison secondaire en tant qu’écouteur de service pour la redirection vers les réplicas secondaires. Pour plus d’informations sur les points de terminaison, consultez Obtenir les points de terminaison principaux et secondaires et l’état du groupe de disponibilité.

• Pour comprendre les bonnes pratiques de monitoring de la disponibilité de vos instances, consultez Gestion et monitoring de SQL Managed Instance avec Azure Arc.

Récupération d'urgence

• Vérifiez que vos instances de SQL Managed Instance avec Arc ont des noms différents pour les sites principaux et secondaires, et que la valeur de nom partagé des sites est identique.

• Effectuez régulièrement des exercices de reprise d’activité afin de valider le processus de basculement.

• Créez un processus pour lancer des basculements manuels et forcés.

• Pour comprendre les bonnes pratiques de monitoring de l’intégrité des clusters et comprendre quand un basculement est nécessaire, consultez Gestion et monitoring de SQL Managed Instance avec Azure Arc.

• Définissez l’enregistrement DNS pour le nom partagé du groupe de disponibilité distribué dans vos serveurs DNS afin d’éviter d’avoir à créer manuellement des enregistrements DNS pendant le basculement.

Étapes suivantes

Pour plus d’informations sur votre parcours cloud hybride et multicloud, consultez les articles suivants :

• Présentation des services de données avec Azure Arc
• Vue d’ensemble : Continuité des activités pour SQL Managed Instance avec Azure Arc
• Validation Kubernetes des services de données avec Azure Arc
• Gérer votre portefeuille dans des opérations hybrides et multiclouds
• Services de données avec Azure Arc pour les scénarios automatisés avec Azure Arc Jumpstart
• Intégrez l’innovation Azure à vos environnements hybrides avec Azure Arc, un parcours d’apprentissage de Microsoft Learn