Migration automatique d’un serveur unique Azure Database pour PostgreSQL vers un serveur flexible
S’APPLIQUE À :
Azure Database pour PostgreSQL : serveur unique
La migration automatique d’Azure Database pour PostgreSQL : serveur unique vers un serveur flexible est une migration initiée par le service qui se déroule pendant une fenêtre de temps d’arrêt planifiée pour un serveur unique, distincte de sa fenêtre de mise à jour corrective ou de maintenance. Le service identifie les serveurs éligibles et envoie des notifications préalables contenant les étapes détaillées du processus de migration automatique. Vous pouvez revoir et ajuster le calendrier de migration si nécessaire ou soumettre une demande d'assistance pour refuser la migration automatique pour vos serveurs.
La migration automatique utilise le service de migration Azure PostgreSQL pour fournir une migration hors connexion résiliente durant la fenêtre de migration planifiée. Le temps d’arrêt varie en fonction des caractéristiques de la charge de travail. Pour connaître les benchmarks de vitesse de migration, consultez Évaluation de la vitesse de migration d’Azure PostgreSQL. Cette migration élimine la nécessité d'une migration manuelle du serveur, ce qui vous permet de bénéficier des fonctionnalités de serveur flexible après la migration, notamment un meilleur rapport prix/performance, un contrôle granulaire de la configuration de la base de données et des fenêtres de maintenance personnalisées.
Remarque
Le service de migration automatique sélectionne un serveur unique à migrer en fonction des critères suivants :
- Serveurs sans fonctionnalité complexe telle que CMK, Microsoft Entra ID, réplica en lecture et point de terminaison privé.
- Taille des données <= 100 Go
- L’accès public est activé
Remarque
Si l’une des fonctionnalités telles que CMK (clé gérée par le client), Microsoft Entra ID, réplica en lecture et point de terminaison privé est utilisée, une planification supplémentaire est nécessaire. Mentionnez les détails dans le formulaire de candidature ci-dessous, et nous prendrons contact avec vous.
Nommer des serveurs uniques pour la migration automatique
Le processus de nomination est destiné aux utilisateurs qui souhaitent effectuer librement le suivi rapide de leur migration vers un serveur flexible. Si vous possédez une charge de travail de serveur unique, vous pouvez vous nommer vous-même (si ce n’est pas déjà planifié par le service) pour la migration automatique. Envoyez les détails de votre serveur via ce formulaire.
Vérifications préalables pour la migration automatique
Vérifiez les prérequis suivants pour garantir la réussite de la migration automatique :
L’instance de serveur unique doit être en état prêt pendant la fenêtre de migration planifiée afin que la migration automatique se produise.
L’instance de Serveur unique doit avoir le paramètre Refuser l’accès au réseau public configuré sur Non. Vous trouverez cette option sous le volet Sécurité de la connexion dans le portail Azure.
Pour l’instance de serveur unique avec SSL activé, vérifiez que tous les certificats (autorité racine DigiCertGlobalRootG2 et autorité racine DigiCertGlobalRootCA) sont disponibles dans le magasin racine approuvé. En outre, si vous avez épinglé le certificat à la chaîne de connexion, créez un certificat d’autorité de certification combiné avec les trois certificats avant la migration automatique planifiée pour garantir la continuité de l’activité après la migration.
Si votre serveur unique source Azure Database pour PostgreSQL a des noms de règles de pare-feu dépassant 80 caractères, renommez-les pour être sûr que la longueur du nom est inférieure à 80 caractères. (La longueur du nom de règle de pare-feu prise en charge sur le serveur flexible est de 80 caractères, tandis que sur le serveur unique, la longueur autorisée est de 128 caractères.)
Processus de migration automatique
Le processus de migration automatique comprend plusieurs phases clés :
Création de serveur flexible cible : un serveur flexible est créé pour correspondre aux performances et au coût de votre référence SKU serveur unique. Il hérite de toutes les règles de pare-feu du serveur unique source.
Migration des données – La migration des données a lieu durant la fenêtre de migration désignée, généralement planifiée en dehors des heures d’ouverture de la région d’hébergement du serveur (si la fenêtre est choisie par le service). Le Single Server source est configuré en lecture seule et toutes les données, schémas, rôles d'utilisateur, privilèges et propriété des objets de la base de données sont migrés vers le serveur flexible. De plus, cette opération permet de copier toutes les règles de pare-feu existantes vers le serveur flexible, ce qui garantit une connectivité ininterrompue.
Commutateur DNS : après la migration des données, un commutateur DNS est effectué, ce qui permet à la chaîne de connexion serveur unique existante de se connecter en toute transparence au nouveau serveur flexible. Les formats de chaîne de connexion du serveur unique et du serveur flexible, ainsi que les formats de nom d’utilisateur (username@server_name et nom d’utilisateur), sont pris en charge sur le serveur flexible migré.
Visibilité du serveur flexible : après une migration de données réussie et un commutateur DNS, le nouveau serveur flexible apparaît sous votre abonnement et peut être géré via le Portail Microsoft Azure ou l’interface CLI.
Chaînes de connexion à serveur unique mises à jour : les chaînes de connexion mises à jour pour le serveur unique hérité sont envoyées via des notifications Service Health sur le Portail Microsoft Azure. Ils sont également accessibles sur la page portail serveur unique sous Paramètres :> chaînes de connexion.
Suppression d’un serveur unique : le serveur unique est conservé pendant sept jours après la migration avant sa suppression.
Comment le serveur flexible PostgreSQL cible est-il approvisionné ?
Le niveau de calcul et la référence SKU du serveur flexible cible sont approvisionnés en fonction du niveau tarifaire et des cœurs virtuels du serveur unique source, comme affiché ci-dessous.
| Niveau tarifaire du serveur unique | VCores du serveur unique | Niveau du serveur flexible | Nom SKU du serveur flexible |
|---|---|---|---|
| De base | 1 | Expansible | B1ms |
| De base | 2 | Expansible | B2s |
| Usage général | 2 | GeneralPurpose | Standard_D2s_v3 |
| Usage général | 4 | GeneralPurpose | Standard_D4s_v3 |
| Usage général | 8 | GeneralPurpose | Standard_D8s_v3 |
| Usage général | 16 | GeneralPurpose | Standard_D16s_v3 |
| Usage général | 32 | GeneralPurpose | Standard_D32s_v3 |
| Usage général | 64 | GeneralPurpose | Standard_D64s_v3 |
| Mémoire optimisée | 2 | MemoryOptimized | Standard_E2s_v3 |
| Mémoire optimisée | 4 | MemoryOptimized | Standard_E4s_v3 |
| Mémoire optimisée | 8 | MemoryOptimized | Standard_E8s_v3 |
| Mémoire optimisée | 16 | MemoryOptimized | Standard_E16s_v3 |
| Mémoire optimisée | 32 | MemoryOptimized | Standard_E32s_v3 |
- La version PostgreSQL, la région, la chaîne de connexion, l’abonnement et le groupe de ressources du serveur flexible cible restent identiques à celles du serveur unique source.
- Pour les serveurs uniques avec moins de 20 Gio de stockage, la taille de stockage est définie sur 32 Gio, car il s’agit de la limite de stockage minimale sur le serveur flexible Azure Database pour PostgreSQL.
- Pour les serveurs uniques avec une exigence de stockage supérieure, le stockage nécessaire qui est alloué équivaut à 1,25 fois plus ou 25 % de plus que le stockage utilisé dans le serveur unique. Pendant la copie de base initiale des données, plusieurs instructions d’insertion sont exécutées sur la cible, ce qui génère des journaux WAL (Write Ahead Logs). Jusqu’à ce que ces fichiers WAL soient archivés, les journaux consomment du stockage sur la cible, d’où la nécessité d’une marge de sécurité.
- Les deux formats de nom d’utilisateur ( username@server_name [serveur unique] et nom d’utilisateur [serveur flexible]) sont pris en charge sur le serveur flexible migré.
- Les deux formats de chaîne de connexion ( serveur unique et serveur flexible) sont pris en charge sur le serveur flexible migré.
Migration automatique entre les versions majeures de PostgreSQL
Cette migration peut impliquer le déplacement de données de PostgreSQL – Serveur unique (versions 9.5, 9.6 ou 10) vers PostgreSQL 11 – Serveur flexible. Notez que ces versions antérieures ont été mises hors service par la communauté PostgreSQL. Pour garantir la sécurité, la stabilité et les performances, il est recommandé d’adopter les versions prises en charge par la communauté.
Quand vous effectuez une migration entre des versions majeures de PostgreSQL, prenez en compte les facteurs clés suivants pour garantir une transition réussie et fluide :
Fonctionnalités mises hors service – Les fonctionnalités qui ont été mises hors service dans les versions antérieures ne sont peut-être plus disponibles dans PostgreSQL 11. Il est important de passer en revue les notes de publication pour identifier les changements cassants ou les fonctionnalités déconseillées susceptibles d’affecter votre application.
Tests de l’application – Effectuez des tests approfondis de votre application sur PostgreSQL 11. Faites attention aux problèmes potentiels liés aux requêtes et fonctions SQL, ou aux outils tiers, car ils peuvent se comporter différemment ou échouer complètement en raison des changements apportés dans la dernière version.
Changements liés à la configuration – Les mises à niveau de versions majeures introduisent souvent des changements dans les paramètres de serveur, soit en ajoutant de nouveaux paramètres, soit en modifiant les valeurs par défaut des paramètres existants. Ces changements peuvent affecter le classement, l’exécution des requêtes et le stockage des données. Pour garantir la compatibilité, testez votre application en fonction de ces paramètres mis à jour, et résolvez les problèmes qui se produisent. Si vous rencontrez des problèmes, utilisez le script fourni dans la section des étapes postérieures à la migration pour copier les paramètres de serveur existants de votre instance de Serveur unique vers l’instance de Serveur flexible migrée automatiquement.
Étapes post-migration
Voici les informations dont vous avez besoin concernant les étapes postérieures à la migration automatique.
Si la migration automatique implique une migration entre les versions majeures de PostgreSQL, testez votre application de manière approfondie pour identifier l’impact des changements cassants et des ajustements de paramètres. Apportez les changements nécessaires pour garantir la compatibilité et des performances optimales.
Tous les scripts Terraform/CLI que vous hébergez pour manager votre instance de serveur unique doivent être mis à jour avec les références du serveur flexible.
Les paramètres de serveur dans le serveur flexible sont paramétrés par rapport aux normes de la communauté. Si vous souhaitez conserver les mêmes valeurs de paramètre de serveur que votre serveur unique, vous pouvez vous connecter via PowerShell et exécuter le script ici pour copier les valeurs des paramètres.
Les paramètres de contrôle d’accès (IAM) de votre serveur flexible sont hérités des paramètres d’abonnement. Si vous avez fourni des attributions de rôles spécifiques au serveur unique, vous devez créer ces attributions de rôles sur votre serveur flexible.
Copiez les paramètres de la page de monitoring (Alertes, Métriques et Paramètres de diagnostic) vers l’instance de Serveur flexible.
Pour activer les analyses des performances des requêtes, vous devez activer le magasin des requêtes sur le serveur flexible, qui n’est pas activé par défaut.
Si une haute disponibilité est nécessaire, vous pouvez l’activer sans temps d’arrêt.
Vérifiez que votre référence SKU de serveur flexible correspond à celle mentionnée dans la notification de migration automatique de Service Health. Si elle est différente, restaurez la référence SKU spécifiée dans la notification. Cela est essentiel pour garantir l’exactitude de la facturation.
Les chaînes de connexion existantes de votre instance de Serveur unique pointent désormais vers l’instance de Serveur flexible. Pour accéder à votre instance de Serveur unique, un nouvel ensemble de chaînes de connexion a été généré. Vous pouvez les récupérer à partir de la notification Service Health envoyée pour la migration automatique de votre instance de Serveur unique.
Gestion des règles VNet dans le serveur flexible
Dans Azure Database pour PostgreSQL – Serveur unique, une règle de réseau virtuel (VNet) est un sous-réseau listé dans la liste ACL (liste de contrôle d’accès) du serveur. Cette règle permet au serveur unique d’accepter la communication provenant de nœuds au sein de ce sous-réseau particulier. Pour le serveur flexible, les règles de réseau virtuel ne sont pas prises en charge. Au lieu de cela, le serveur flexible permet la création de points de terminaison privés, ce qui permet au serveur de fonctionner au sein de votre réseau virtuel. Un point de terminaison privé affecte une adresse IP privée au serveur flexible, et tout le trafic entre votre réseau virtuel et le serveur transite en sécurité via le réseau principal Azure, ce qui élimine la nécessité d’une exposition à l’Internet public.
Après la migration, vous devez ajouter un point de terminaison privé à votre instance de Serveur flexible pour tous les sous-réseaux qui étaient couverts par des règles de VNet (réseau virtuel) sur votre instance de Serveur unique. Vous pouvez effectuer ce processus en utilisant le Portail Microsoft Azure ou Azure CLI. Une fois cette étape terminée, votre connectivité réseau reste intacte sur le serveur flexible après la migration depuis un serveur unique.
Sauvegarde de conservation à long terme
La migration automatique de serveurs uniques ne configure pas automatiquement la sauvegarde de rétention à long terme (LTR) après la migration vers un serveur flexible. Vous pouvez sauvegarder le serveur flexible Azure Database for PostgreSQL avec une conservation à long terme à l'aide d'Azure Backup.
Comment vérifier si votre serveur unique est programmé pour une migration automatique
Pour déterminer si votre Single Server est sélectionné pour la migration automatique, procédez comme suit :
Notifications Intégrité des services : dans le Portail Microsoft Azure, accédez aux événements Intégrité des services > Maintenance planifiée. Recherchez les événements étiquetés « Notification pour la migration automatique planifiée vers un serveur unique Azure Database pour PostgreSQL ». Les notifications sont envoyées 30, 14 et 7 jours avant la date de migration, et à nouveau pendant les étapes de la migration : en cours, terminée, et six jours avant que le serveur unique ne soit mis hors service.
Remarque
Par défaut, ces notifications n'arrivent pas dans votre boîte de réception. Pour les recevoir par e-mail ou SMS, vous devez configurer les Azure Service Health en suivant les étapes ci-dessous
Page Vue d’ensemble du serveur unique : accédez à votre instance de serveur unique dans le Portail Microsoft Azure et consultez la page Vue d’ensemble. Si la migration automatique est planifiée, vous trouverez ici les détails correspondants. Vous pourrez notamment différer la migration d’un mois à la fois, ou la replanifier dans le mois en cours.
Remarque
La planification de la migration est verrouillée 7 jours avant la fenêtre de migration planifiée, période pendant laquelle vous ne pouvez pas replanifier la migration.
Notifications par e-mail Azure CXP : Azure Customer Experience(CXP) envoie également des e-mails directs aux rôles classiques et aux rôles RBAC associés à l’abonnement contenant le serveur unique, fournissant des informations sur les migrations automatiques à venir.
Forum Aux Questions (FAQ)
Q. Pourquoi je fais l’objet d’une migration automatique ?
A. Votre instance de serveur unique Azure Database pour PostgreSQL est éligible pour la migration automatique vers notre offre phare de serveur flexible Azure Database pour PostgreSQL. Cette migration automatique supprime le traitement lié à la migration manuelle de votre serveur. Vous pouvez bénéficier des avantages du serveur flexible, notamment de meilleures performances à un meilleur prix, un contrôle précis sur la configuration de la base de données et des fenêtres de maintenance personnalisées.
Q : Comment se déroule la migration automatique ? Quels sont les éléments qu’il migre ?
A. Le serveur flexible est configuré pour correspondre aux mêmes vCores et stockage que celui de votre serveur unique. Une fois que le serveur unique source est mis en lecture seule, le schéma et les données sont copiés sur le serveur flexible cible. Le commutateur DNS est effectué pour router toutes les connexions existantes vers la cible et le serveur flexible cible est mis en ligne. La migration automatique migre les bases de données (y compris le schéma, les données, les utilisateurs/rôles et les privilèges). La migration s’effectue hors connexion, ce qui implique un temps d’arrêt allant de quelques minutes à 2 heures, selon la taille de votre charge de travail. Pour connaître les benchmarks de vitesse de migration, consultez Évaluation de la vitesse de migration d’Azure PostgreSQL.
Q : Comment puis-je configurer ou afficher des alertes de migration automatique ?
A. Voici les façons dont vous pouvez configurer des alertes :
- Configurez des alertes d’intégrité des services pour recevoir des notifications de la planification et la progression de la migration automatique par e-mail/SMS en suivant les étapes ici.
- Vérifiez la notification de migration automatique sur le Portail Azure en suivant les étapes ici.
Q : Comment différer la migration planifiée de mon serveur unique ?
A. Vous pouvez vérifier la planification de la migration en accédant à la page de Présentation de votre instance de serveur unique. Si vous souhaitez différer la migration, vous pouvez différer d’un mois au maximum en accédant à la page Présentation de votre instance de serveur unique sur le portail Azure. Vous pouvez replanifier la migration en sélectionnant une autre fenêtre de migration dans un délai d’un mois. Les détails de la migration sont verrouillés sept jours avant la fenêtre de migration planifiée, après quoi vous ne pourrez pas replanifier. Cette migration automatique peut être différée mensuellement jusqu’au 28 mars 2025.
Q : Comment désactiver une migration automatique planifiée de mon serveur unique ?
A. Si vous souhaitez refuser la migration automatique, vous pouvez créer un ticket de support à cet effet.
Q : Quelles étapes post-migration dois-je suivre si mon serveur unique utilise des règles VNet ?
R : Les règles VNet ne sont pas prises en charge sur le serveur flexible. Consultez cette section
Q : Dois-je reconfigurer les sauvegardes de rétention à long terme sur un serveur flexible ?
R : Oui. Veuillez vous référer à cette section
Q : Quel nom d’utilisateur et quelle chaîne de connexion sont pris en charge pour le serveur flexible migré ?
A. Les formats de nom d’utilisateur nom d’utilisateur@nom_serveur (format serveur unique) et nom d’utilisateur (format serveur flexible) sont pris en charge pour le serveur flexible migré. Par conséquent, vous n’êtes pas obligé de les mettre à jour pour maintenir la continuité de votre application après la migration. En outre, les deux formats de chaîne de connexion (format serveur unique et flexible) sont également pris en charge pour le serveur flexible migré.
Q : Verrai-je une différence de prix sur le déplacement potentiel du serveur unique de base PostgreSQL vers le serveur flexible sur le PostgreSQL ??
A. Un petit nombre de serveurs seulement peuvent faire l’objet d’une révision mineure du prix après la migration, car la limite de stockage minimale sur les deux offres est différente (5 Gio sur un serveur unique et 32 Gio sur un serveur flexible). Le coût de stockage du serveur flexible est légèrement supérieur à celui du serveur unique. Toute augmentation de prix est compensée par un meilleur débit et de meilleures performances par rapport au serveur unique. Pour plus d’informations sur la tarification d’une instance de Serveur flexible, consultez ce document
Q : Que se passe-t-il si je n’effectue pas la migration, ou si mon serveur n’est pas migré automatiquement d’ici le 28 mars 2025?
R : Après la date d’échéance de mise hors service du 28 mars 2025, tous les serveurs uniques existants qui n’ont pas été migrés seront migrés de force vers une instance de Serveur flexible. Les serveurs disposant de modules complémentaires telles que CMK ou le point de terminaison privé nécessitent des actions supplémentaires de la part de l’utilisateur après la migration pour garantir un fonctionnement normal. Il n’y a aucune extension à la date de mise hors service.