Configurer la haute disponibilité pour le serveur flexible Azure Database pour PostgreSQL

Cet article explique comment activer ou désactiver la haute disponibilité sur votre serveur flexible Azure Database pour PostgreSQL. Les informations s’appliquent si vous utilisez des serveurs dans la même zone ou à l’aide d’un modèle de déploiement redondant interzone. Cet article explique comment activer ou désactiver la haute disponibilité sur votre serveur flexible Azure Database pour PostgreSQL. Les informations s’appliquent si vous utilisez des serveurs dans la même zone ou à l’aide d’un modèle de déploiement redondant interzone.

La fonctionnalité de haute disponibilité déploie des réplicas principaux et de secours physiquement distincts. Vous pouvez provisionner les réplicas dans la même zone de disponibilité ou dans différentes zones, en fonction du modèle de déploiement que vous choisissez. Pour plus d’informations, consultez l’article sur les concepts de haute disponibilité. Vous pouvez activer la haute disponibilité pendant ou après la création de votre serveur flexible Azure Database pour PostgreSQL. La fonctionnalité de haute disponibilité déploie des réplicas principaux et de secours physiquement distincts. Vous pouvez provisionner les réplicas dans la même zone de disponibilité ou dans différentes zones, en fonction du modèle de déploiement que vous choisissez. Pour plus d’informations, consultez l’article sur les concepts de haute disponibilité. Vous pouvez activer la haute disponibilité pendant ou après la création de votre serveur flexible Azure Database pour PostgreSQL.

Activer la haute disponibilité pour les serveurs existants

Vous pouvez activer la haute disponibilité sur un serveur flexible Azure Database pour PostgreSQL existant à tout moment. Lorsque vous activez la haute disponibilité, le service crée une réplique de secours qui reflète votre serveur principal. En fonction de la capacité régionale et de vos choix de configuration, le serveur de secours peut être déployé dans une zone de disponibilité différente pour une protection maximale ou dans la même zone que le serveur principal. Vous pouvez activer la haute disponibilité sur un serveur flexible Azure Database pour PostgreSQL existant à tout moment. Lorsque vous activez la haute disponibilité, le service crée une réplique de secours qui reflète votre serveur principal. En fonction de la capacité régionale et de vos choix de configuration, le serveur de secours peut être déployé dans une zone de disponibilité différente pour une protection maximale ou dans la même zone que le serveur principal.

Utilisez le portail Azure :

  1. Sélectionnez votre serveur flexible Azure Database pour PostgreSQL. Utilisation du portail Azure :

  2. Sélectionnez votre serveur flexible Azure Database pour PostgreSQL.

  3. Dans le menu des ressources, sous la section Paramètres , sélectionnez Haute disponibilité.

L’option de résilience zonale contrôle si votre serveur est protégé entre les zones de disponibilité. Deux options s'offrent à vous :

  • Désactivé (99.9% SLA) : la haute disponibilité n’est pas configurée.
  • Activé (99.99% SLA) : lorsque vous sélectionnez cette option, Azure tente de créer le serveur de secours dans une zone de disponibilité différente de celle du serveur principal. Cette option vous offre la meilleure protection contre les défaillances au niveau de la zone.

Si vous activez la résilience zonale mais que votre région ne dispose pas de capacité pour une configuration redondante interzone, une case supplémentaire s’affiche sous l’option Activé (99,99% SLA). Cochez cette case pour autoriser la création du serveur de secours dans la même zone que le serveur principal. Lorsque la capacité zonale devient disponible, Azure migre automatiquement vos charges de travail de la même zone vers une zone redondante.

  1. Si vous n’avez pas activé la résilience zonale, sélectionnez l’option Activé .

    Capture d’écran montrant la page Haute disponibilité pour la configuration de la haute disponibilité.

  2. Lorsque vous sélectionnez l’option Activé, l’option redondance de zone est appliquée par défaut pour les régions qui prennent en charge les zones de disponibilité. Cette configuration protège contre les défaillances zonales.

    Capture d’écran montrant la case d’option sélectionnée pour activer la haute disponibilité.

  3. Si la région n’a pas de capacité zonale, pour vous assurer que la haute disponibilité (HA) est activée dans votre région préférée, cochez la case sous l’option activée pour autoriser la création de haute disponibilité avec Same-Zone mode de la région :

    Capture d’écran montrant la sélection de la même option de zone pour la haute disponibilité.

  4. Lorsque vous avez terminé de configurer les paramètres, sélectionnez Enregistrer pour appliquer les modifications.

  5. Une boîte de dialogue affiche l’augmentation du coût associée au déploiement du serveur de secours. Si vous décidez de continuer, sélectionnez Activer la haute disponibilité.

    Capture d’écran montrant la boîte de dialogue pour confirmer l’activation de la haute disponibilité.

  6. Un nouveau déploiement est lancé pour activer la haute disponibilité sur votre serveur flexible Azure Database pour PostgreSQL.

    Capture d’écran montrant le déploiement en cours d’une configuration à haute disponibilité.

  7. Une fois le déploiement terminé, vous pouvez sélectionner Accéder à la ressource pour revenir à votre serveur flexible Azure Database pour PostgreSQL.

    Capture d’écran montrant le déploiement correctement terminé pour activer une configuration à haute disponibilité.

Désactiver la haute disponibilité

Vous pouvez désactiver la haute disponibilité pour votre serveur flexible Azure Database pour PostgreSQL lorsque vous n’avez plus besoin de la protection d’une réplique de secours. La désactivation de la haute disponibilité supprime le serveur de secours et réduit les coûts, mais votre serveur n’est plus protégé contre les défaillances de zone ou de serveur.

Utilisez le portail Azure :

  1. Sélectionnez votre serveur flexible Azure Database pour PostgreSQL.

  2. Dans le menu des ressources, sous la section Paramètres , sélectionnez Haute disponibilité.

  3. Si la haute disponibilité est activée, la case d’option Activée pour la résilience zonale est déjà sélectionnée. En outre, le mode haute disponibilité est défini sur le mode configuré et la valeur d’état de haute disponibilité est généralement saine.

    Capture d’écran montrant le volet de configuration de la haute disponibilité, avec des options de haute disponibilité déjà sélectionnées et un état sain.

  4. Sélectionnez le bouton Désactivée pour désactiver la haute disponibilité.

    Capture d’écran montrant la case à cocher pour activer la haute disponibilité désactivée.

  5. Sélectionnez Enregistrer pour appliquer les modifications.

  6. Une boîte de dialogue affiche la réduction des coûts associée à la suppression du serveur de secours. Si vous décidez de continuer, sélectionnez Désactiver la haute disponibilité.

    Capture d’écran montrant la boîte de dialogue pour confirmer la désactivation de la haute disponibilité.

  7. Un déploiement démarre. Une fois l’opération terminée, une notification indique que vous avez désactivé la haute disponibilité.

    Capture d’écran montrant une notification sur la désactivation réussie de la haute disponibilité.

Activer la disponibilité critique pour l'entreprise (haute disponibilité) lors du provisionnement du serveur

Vous pouvez configurer la haute disponibilité lorsque vous créez d’abord votre serveur flexible Azure Database pour PostgreSQL. En activant la haute disponibilité pendant l’approvisionnement, vous déployez un réplica de secours en même temps que votre serveur principal. Vous bénéficiez donc d’une protection immédiate contre les défaillances de zone ou de serveur.

Utilisez le portail Azure :

  1. Lors de l’approvisionnement d’un nouveau serveur flexible Azure Database pour PostgreSQL, accédez à la section Critique pour l’entreprise (haute disponibilité). Sélectionnez l’option Activé dans la section Résilience zonale .

    • Par défaut, le serveur tente de créer le serveur de secours dans une zone de disponibilité différente avec le mode HA redondant par zone pour une résilience zonale maximale.

    Capture d’écran montrant l’activation de la haute disponibilité avec l’option de redondance interzone.

    • Si la capacité zonale n’est pas disponible, sélectionnez la case à cocher Autoriser le secours dans la même zone si la résilience zonale échoue en tant que solution de secours. Si vous ne sélectionnez pas cette option, vous ne pouvez pas passer à l’étape suivante dans le flux de travail de création. Cette vérification garantit que la haute disponibilité reste activée. Lorsque la capacité zonale devient disponible, Azure migre automatiquement vos charges de travail de HA même zone vers HA résiliente entre zones.

      Capture d’écran montrant le message d’erreur de validation pour l’option haute disponibilité dans la même zone.

    • Après avoir coché la case, passez à la section Authentification dans le flux de travail de création.

      Capture d’écran montrant la haute disponibilité avec l’option HA monozone.

  2. Sélectionnez une zone spécifique pour le serveur principal en définissant Zone de disponibilité sur n’importe quelle valeur autre que Aucune préférence.

    Capture d’écran montrant la sélection de zones de disponibilité spécifiques pour le serveur principal.

Lancer un basculement forcé

Suivez ces étapes pour forcer le basculement de votre serveur principal vers le serveur de secours dans Azure Database pour PostgreSQL.

Lorsque vous lancez un basculement forcé, le serveur principal tombe immédiatement en panne et déclenche un basculement vers le serveur de secours. Le lancement d’un basculement forcé est utile lorsque vous souhaitez tester la façon dont un basculement provoqué par une panne non planifiée affecte votre charge de travail.

Important

  • N’effectuez pas de basculements consécutifs sans pause. Attendez au moins 15 à 20 minutes entre les basculements. Ce temps d’attente permet au nouveau serveur de secours d’être entièrement établi.

  • L’heure globale de l’opération de bout en bout, comme indiqué sur le portail, peut être plus longue que le temps d’arrêt réel que l’application rencontre. Vous devez mesurer le temps d’arrêt du point de vue de l’application.

Utilisez le portail Azure :

  1. Sélectionnez votre serveur flexible Azure Database pour PostgreSQL sur lequel la haute disponibilité est activée.

  2. Dans le menu des ressources, sous la section Paramètres , sélectionnez Haute disponibilité.

  3. Si les serveurs principaux et de secours sont déployés dans différentes zones, notez les valeurs affectées à la zone de disponibilité principale et à la zone de disponibilité de secours. Ces valeurs s’inversent une fois l’opération de basculement terminée.

    Capture d’écran montrant les zones de disponibilité du principal et du secondaire.

  4. Sélectionnez Basculement forcé pour démarrer la procédure de basculement manuelle. Une boîte de dialogue vous informe du temps d’arrêt attendu jusqu’à ce que le basculement se termine. Si vous décidez de continuer, sélectionnez Démarrer le basculement forcé.

    Capture d’écran montrant la boîte de dialogue affichée avant le lancement d’un basculement forcé.

  5. Une notification s’affiche et mentionne qu’un basculement est en cours.

    Capture d'écran montrant une notification indiquant qu'un basculement est en cours après le lancement d'un basculement forcé.

  6. Une fois le basculement effectué vers le serveur de secours, une notification vous informe de la fin.

    Capture d’écran montrant la notification affichée une fois le basculement forcé terminé.

  7. Si les serveurs principaux et de secours sont déployés dans différentes zones, vérifiez que les valeurs de la zone de disponibilité principale et de la zone de disponibilité de secours sont inversées par rapport à la façon dont ils étaient avant le démarrage du basculement.

Initier un basculement planifié

Suivez ces étapes pour effectuer un basculement planifié de votre serveur principal vers le serveur de secours dans Azure Database pour PostgreSQL. Lorsque vous lancez cette opération, elle prépare le serveur de secours, puis effectue le basculement.

Cette opération de basculement fournit le moins de temps d’arrêt, car elle effectue un basculement approprié vers le serveur de secours. Il est utile pour les situations telles que le retour du serveur principal vers votre zone de disponibilité préférée après un basculement inattendu.

Important

  • N’effectuez pas de basculements consécutifs sans pause. Attendez au moins 15 à 20 minutes entre les basculements. Ce temps d’attente permet au nouveau serveur de secours d’être entièrement établi.

  • Effectuez des basculements planifiés pendant les périodes de faible activité.

  • L’heure globale de l’opération de bout en bout, comme indiqué sur le portail, peut être plus longue que le temps d’arrêt réel que l’application rencontre. Vous devez mesurer le temps d’arrêt du point de vue de l’application.

Utilisez le portail Azure :

  1. Sélectionnez votre serveur flexible Azure Database pour PostgreSQL sur lequel la haute disponibilité est activée.

  2. Dans le menu des ressources, sous la section Paramètres , sélectionnez Haute disponibilité.

  3. Si les serveurs principaux et de secours sont déployés dans différentes zones, notez les valeurs affectées à la zone de disponibilité principale et à la zone de disponibilité de secours. Ces valeurs s’inversent une fois l’opération de basculement terminée.

    Capture d’écran montrant les zones de disponibilité du principal et du secondaire.

  4. Sélectionnez Basculement planifié pour démarrer la procédure de basculement manuelle. Une boîte de dialogue vous informe du temps d’arrêt attendu jusqu’à ce que le basculement se termine. Si vous décidez de continuer, sélectionnez Démarrer le basculement planifié.

    Capture d’écran montrant la boîte de dialogue affichée avant le déclenchement d’un basculement planifié.

  5. Une notification s’affiche et mentionne que le basculement est en cours.

    Capture d'écran montrant une notification indiquant qu'un basculement est en cours après le lancement d'un basculement planifié.

  6. Une fois le basculement effectué vers le serveur de secours, une notification vous informe de la fin.

    Capture d’écran montrant la notification affichée lorsqu’un basculement planifié se termine.

  7. Si le mode haute disponibilité est configuré comme redondant interzone, vérifiez que les valeurs de la Zone de disponibilité principale et de la Zone de disponibilité de secours sont désormais inversées.

Limitations et considérations

  • Lorsque vous activez ou désactivez la haute disponibilité sur un serveur flexible Azure Database pour PostgreSQL, le service ne modifie pas d'autres paramètres. Ces paramètres incluent la configuration réseau, les paramètres de pare-feu, les paramètres et la rétention des sauvegardes. L’activation ou la désactivation de la haute disponibilité est une opération en ligne. Cette opération n’affecte pas la connectivité et les opérations de votre application.

  • Azure Database pour PostgreSQL prend en charge la haute disponibilité avec les deux réplicas déployés dans la même zone. Vous pouvez utiliser cette configuration dans toutes les régions prises en charge. Toutefois, la haute disponibilité avec redondance de zone n’est disponible que dans certaines régions.

  • Le niveau Burstable ne prend pas en charge la haute disponibilité. Seuls les niveaux usage général et mémoire optimisée prennent en charge la haute disponibilité.

  • Si vous déployez un serveur dans une région qui se compose d’une seule zone de disponibilité, vous pouvez activer la haute disponibilité uniquement en mode de même zone. Si Microsoft ajoute plusieurs zones de disponibilité à cette région à l'avenir, vous pourrez déployer de nouveaux serveurs Azure Database pour PostgreSQL Flexible Server avec une haute disponibilité configurée en mode même zone ou redondance interzone.

    Toutefois, vous ne pouvez pas activer directement la haute disponibilité en mode redondant interzone pour n’importe quel serveur que vous avez déployé dans la région lorsque la région se compose d’une seule zone de disponibilité. Pour contourner ce problème, vous pouvez utiliser l’option de restauration ou l’option de réplica en lecture :

Option de restauration

  1. Restaurer vers le dernier point de restauration.
  2. Après avoir créé le nouveau serveur, activez la haute disponibilité avec redondance de zone.
  3. Après la vérification des données, vous pouvez éventuellement supprimer l’ancien serveur.
  4. Veillez à modifier les chaînes de connexion de vos clients pour qu’ils pointent vers votre serveur nouvellement restauré.

Option de réplica en lecture

  1. Créez une réplique en lecture dans la même région que votre serveur principal.

  2. Effectuez la promotion du réplica en lecture pour qu’il devienne le nouveau serveur primaire.

  3. Pour conserver le nom d’origine, utilisez des points de terminaison virtuels ou supprimez l’ancien serveur primaire, puis créez et procédez à la promotion d’un nouveau réplica en lecture.

  4. Pour les utilisateurs du portail, activez la résilience zonale. Pour les outils de développement, définissez la haute disponibilité avec l’option Zone-Redundant.

  5. Créez une réplique en lecture dans la même région que votre serveur principal.

  6. Effectuez la promotion du réplica en lecture pour qu’il devienne le nouveau serveur primaire.

  7. Pour conserver le nom d’origine, utilisez des points de terminaison virtuels ou supprimez l’ancien serveur primaire, puis créez et procédez à la promotion d’un nouveau réplica en lecture.

  8. Pour les utilisateurs du portail, activez la résilience zonale. Pour les outils de développement, définissez la haute disponibilité avec l’option Zone-Redundant.

Contenu connexe

  • Last updated on