Utiliser les planifications de maintenance pour gérer les mises à jour et la maintenance des services

La fonctionnalité de planification de maintenance intègre les notifications de maintenance planifiée de Service Health, l’analyse de vérification de Resource Health et le service de planification de la maintenance pour le pool SQL Synapse (entrepôt de données) dans Azure Synapse Analytics.

Vous devez utiliser la planification de maintenance afin de choisir la bonne fenêtre pour recevoir les nouvelles fonctionnalités, les mises à niveau et les correctifs. Vous devrez choisir une fenêtre de maintenance principale et secondaire au cours d’une période de sept jours. Chaque fenêtre doit se trouver dans des plages de jours distinctes.

Par exemple, vous pouvez planifier une fenêtre principale du samedi 22:00 au dimanche 01:00, et une fenêtre secondaire le mercredi de 19:00 à 22:00. Si la maintenance ne peut pas être effectuée pendant la fenêtre de maintenance principale, une nouvelle tentative a lieu pendant la fenêtre secondaire. À l’occasion, la maintenance du service peut se produire à la fois pendant les fenêtres principale et secondaire. Pour garantir l’exécution rapide de toutes les opérations de maintenance, les niveaux d’entrepôt de données DW400c et inférieurs peuvent effectuer la maintenance en dehors d’une fenêtre de maintenance désignée.

Pendant le déploiement, une planification de maintenance définie par le système est appliquée à toutes les instances d’entrepôt de données récemment créées. La planification peut être modifiée une fois le déploiement terminé.

Au moment de choisir une fenêtre de maintenance, vous devez sélectionner une heure de début et définir une durée maximale. La « durée maximale d’une fenêtre de maintenance » détermine la période pendant laquelle des tâches de maintenance sont effectuées. Cette période peut être comprise entre trois (3) et huit (8) heures, avec une configuration minimale de trois (3) heures. Pendant cette période, votre entrepôt de données est temporairement hors connexion, car votre pool dédié est déplacé vers une capacité mise à niveau en tirant parti d’un processus similaire à suspendre/reprendre. Dans des conditions classiques, cette opération s’effectue en moins de 30 minutes, mais il est important de noter que dans certains cas, elle peut prendre plus de temps. Par exemple, s’il existe des transactions actives au début de la maintenance, elles sont annulées et restaurées, ce qui peut entraîner des retards dans la restauration du service en ligne. Pour éviter ce scénario, nous vous recommandons de veiller à ce qu’aucune transaction de longue durée ne soit active au début de votre fenêtre de maintenance.

Toutes les opérations de maintenance doivent se terminer dans les fenêtres de maintenance spécifiées, sauf si nous sommes obligés de déployer une mise à jour urgente. Si votre entrepôt de données est suspendu pendant une maintenance planifiée, il sera mis à jour pendant l’opération de reprise. Vous êtes averti une fois la maintenance de votre entrepôt de données terminée.

Notes

• Les fenêtres de maintenance ne s’appliquent pas aux niveaux de performance DW400c ou inférieurs. Ils peuvent à tout moment faire l’objet d’une maintenance.
• DW400c et les niveaux inférieurs peuvent rencontrer plusieurs brèves pertes de connectivité à différents moments de la fenêtre de maintenance.

Alertes et supervision

L’intégration des notifications Azure Service Health et du moniteur de vérifications Azure Resource Health permet aux clients d’être informés des activités de maintenance imminentes. Cette automatisation tire parti d’Azure Monitor. Vous décidez comment vous souhaitez être informé des événements de maintenance imminente. Vous pouvez également choisir les flux automatisés qui vous aideront à gérer les temps d’arrêt et à minimiser l’impact sur les opérations.

Notes

Un préavis est envoyé 24 heures avant chaque événement de maintenance. Dans le cas où nous sommes amenés à déployer une mise à jour critique dans le temps, les temps de notification avancés peuvent être considérablement réduits. Cela peut se produire en dehors d’une fenêtre de maintenance identifiée en raison de la nature critique de la mise à jour.

Si vous avez reçu une notification pour une prochaine maintenance mais que la maintenance ne peut pas être effectuée pendant la période annoncée, vous recevrez une notification d’annulation. La maintenance reprendra lors de la prochaine période de maintenance planifiée.

Tous les événements de maintenance actifs sont affichés dans la section Service Health - Maintenance planifiée. L’historique d’Azure Service Health contient un enregistrement complet des événements passés. Vous pouvez surveiller la maintenance via le tableau de bord du portail de vérification Azure Service Health pendant un événement actif.

Disponibilité de la planification de maintenance

Même si la planification de la maintenance n’est pas encore disponible dans votre région, vous pouvez l’afficher et la modifier à tout moment. Quand la planification de la maintenance sera disponible dans votre région, la planification identifiée deviendra immédiatement active dans votre pool SQL Synapse.

Afficher une planification de maintenance

Par défaut, toutes les instances d’entrepôt de données récemment créées ont deux fenêtres de maintenance (une principale et une secondaire) de huit heures, appliquées pendant le déploiement. Comme indiqué ci-dessus, vous pouvez modifier les fenêtres dès que le déploiement est terminé. Aucune maintenance ne peut avoir lieu en dehors des fenêtres de maintenance définies, sans notification préalable.

Pour voir la planification de maintenance qui a été appliquée à votre pool SQL Synapse, effectuez les étapes suivantes :

1. Connectez-vous au portail Azure.
2. Sélectionnez le pool SQL Synapse que vous voulez voir.
3. Le pool SQL Synapse sélectionné s’ouvre dans le panneau Vue d’ensemble. La planification de maintenance appliquée à l’entrepôt de données s’affiche sous Planification de la maintenance.

Ignorer ou modifier un calendrier de maintenance

Pour garantir le respect des dernières exigences de sécurité, nous ne pouvons pas prendre en charge les demandes pour ignorer ou retarder ces mises à jour. Toutefois, certaines options peuvent vous permettre d’ajuster votre fenêtre de maintenance si vous utilisez les niveaux d’entrepôt de données DW500c et supérieurs dans le cycle actuel, en fonction de votre situation :

• Si vous recevez une notification de maintenance en attente et que vous avez besoin de plus de temps pour terminer vos travaux ou avertir votre équipe, vous pouvez modifier l’heure de début de la fenêtre tant que vous le faites avant le début de la fenêtre de maintenance définie. Votre fenêtre sera déplacée plus loin dans le temps au sein du cycle.

• Vous pouvez déclencher manuellement la maintenance en suspendant et en reprenant (ou en mettant à l’échelle) votre pool dédié SQL après le début d’un cycle pour lequel une notification « En attente » a été reçue. Le cycle de maintenance du week-end commence le samedi à 00:00 UTC ; le cycle de maintenance en milieu de semaine commence le mardi à 12:00 UTC.

• Bien que nous ayons besoin d’une fenêtre minimale de 3 heures, cette opération se termine en moins de 30 minutes dans des conditions normales. Toutefois, il est important de noter que dans certains cas, elle peut prendre plus de temps. Par exemple, s’il existe des transactions actives au début de la maintenance, elles sont annulées et restaurées, ce qui peut entraîner des retards dans la restauration du service en ligne. Pour éviter ce scénario, nous vous recommandons de veiller à ce qu’aucune transaction de longue durée ne soit active au début de votre fenêtre de maintenance.

Notes

• Si vous modifiez la fenêtre par une heure de début avant l’heure actuelle réelle, la maintenance est immédiatement déclenchée et, s’il existe des transactions actives au démarrage de la maintenance, elles sont abandonnées et restaurées.
• Une fois l’opération de suspension et de reprise terminée pour lancer la maintenance, au lieu de recevoir une notification confirmant l’achèvement de cette dernière, vous êtes averti qu’elle a été annulée.
• Si vous utilisez DW400c ou une version antérieure, bien que vous puissiez modifier la planification de maintenance, elle ne sera pas respectée, car il s’agit d’un niveau de performances inférieur. Comme évoqué précédemment, ces niveaux d’entrepôt de données peuvent faire l’objet d’une maintenance à tout moment avec le cycle de maintenance.

Identification des fenêtres principale et secondaire

Les fenêtres principale et secondaire doivent avoir des plages de jour distinctes. Par exemple, une fenêtre principale allant du mardi au jeudi, et une fenêtre secondaire allant du samedi au dimanche. Les termes « Principal » et « Secondaire » doivent être considérés comme la « Fenêtre 1 » et la « Fenêtre 2 », respectivement. Cela signifie que l’une ou l’autre des fenêtres peut être choisie dans n’importe quel ordre pour le déploiement des mises à niveau de maintenance.

Pour changer la planification de maintenance de votre pool SQL Synapse, effectuez les étapes suivantes :

1. Connectez-vous au portail Azure.

2. Sélectionnez le pool SQL Synapse que vous voulez mettre à jour. La page s’ouvre dans le panneau Vue d’ensemble. Ouvrez la page de paramètres de planification de maintenance en sélectionnant le lien Résumé de la planification de maintenance du panneau Vue d’ensemble. Ou sélectionnez l’option Planification de la maintenance dans le menu de ressource à gauche.

   

3. Identifiez la plage de jours par défaut pour votre fenêtre de maintenance principale à l’aide des options en haut de la page. Cette sélection détermine si la fenêtre principale a lieu un jour de semaine ou pendant le week-end. Votre sélection met à jour les valeurs des listes déroulantes. Dans la préversion, il est possible que certaines régions ne prennent pas en charge l’ensemble complet des options Jour disponibles.

   

4. Choisissez vos fenêtres de maintenance principale et secondaire par défaut à l’aide des zones de liste déroulante :

   • Jour : Jour par défaut où doit avoir lieu la maintenance pendant la fenêtre sélectionnée.
   • Heure de début : heure par défaut à laquelle doit commencer la fenêtre de maintenance.
   • Fenêtre de temps : Durée par défaut de la fenêtre de temps.

   La zone Résumé de la planification en bas du panneau est mise à jour avec les valeurs que vous avez sélectionnées.

5. Sélectionnez Enregistrer. Un message s’affiche pour confirmer que votre nouvelle planification est maintenant active.

   Vous pouvez à tout moment mettre à jour les sélections de la fenêtre Jour, Heure de début et Temps (y compris la fenêtre de 8 heures par défaut). Si vous enregistrez une planification dans une région qui ne prend pas en charge la planification de maintenance, le message suivant s’affiche. Vos paramètres sont enregistrés et deviennent actifs dès que la fonctionnalité est disponible dans la région que vous avez sélectionnée.

   

Forum aux questions

Quelle est la fréquence de maintenance attendue ?

La maintenance peut se produire plus d’une fois par mois, car elle peut inclure les mises à jour du système d’exploitation, les correctifs de sécurité et les pilotes, les mises à jour internes de l’infrastructure Azure et les correctifs et mises à jour DW. Chaque client dispose d’un calendrier de cycles de maintenances bi-hebdomadaires, du samedi au dimanche et du mardi au jeudi.

Quelles modifications ont été apportées une fois la maintenance terminée, même si ma version de pool SQL dédiée reste la même ?

Une fois qu’une mise à jour de maintenance est terminée, la version du pool SQL peut rester inchangée. Cela s’explique par le fait que la maintenance peut inclure les mises à jour du système d’exploitation, les correctifs de sécurité et les pilotes, les mises à jour internes de l’infrastructure Azure et les correctifs et mises à jour DW. Vous verrez une modification de la version du pool dédié SQL uniquement si un correctif ou une mise à jour Synapse DW est inclus dans la maintenance.

Est-il possible de mettre à niveau la version de mon pool SQL dédié à la demande ?

• Non, la maintenance planifiée gère la gestion des pools SQL dédiés. Toutefois, vous pouvez avoir certaines options pour déclencher une maintenance une fois le cycle démarré, en fonction de votre situation. Consultez Ignorer ou modifier un calendrier de maintenance
• Il est important de garder à l’esprit que le pool SQL dédié est une fonctionnalité PaaS (Platform as a Service). Cela implique que Microsoft Azure gère toutes sortes de tâches liées au service, telles que l’infrastructure, la maintenance, les mises à jour et l’évolutivité. La maintenance planifiée peut être suivie en définissant une alerte/notification afin de rester informé de l’activité de maintenance imminente.

Quelles modifications, le cas échéant, doivent être apportées avant ou après la fin de la maintenance du pool SQL dédié ?

• Pendant la maintenance, votre service sera brièvement mis hors connexion, comme qui se produit lors d’une pause, d’une reprise ou d’une opération de mise à l’échelle. En règle générale, l’opération de maintenance globale est terminée en moins de 30 minutes. Toutefois, cela peut prendre un peu plus de temps, en fonction de l’activité de base de données pendant la fenêtre de maintenance. Nous vous recommandons de suspendre l’ETL, les mises à jour de tables et en particulier les opérations transactionnelles pour éviter de rallonger la durée de la maintenance. Par exemple :
• Si votre instance est extrêmement occupée pendant la fenêtre planifiée, en particulier avec des activités de mise à jour et de suppression fréquentes, l’opération de maintenance peut prendre plus de temps que la normale. Pour réduire le risque de rallonger l’activité de maintenance, nous vous recommandons de limiter l’activité à une majorité de requêtes en lecture seule sur la base de données si possible, et surtout d’éviter les requêtes transactionnelles longues (voir l’élément suivant).
• S’il existe des transactions actives au début de la maintenance, elles sont annulées et restaurées, ce qui peut entraîner des retards dans la restauration du service en ligne. Pour éviter ce scénario, nous vous recommandons de veiller à ce qu’aucune transaction de longue durée ne soit active au début de votre fenêtre de maintenance.

Nous avons été avertis d’une prochaine maintenance planifiée du pool SQL dédié avec l’ID de suivi 0000-000, mais elle a ensuite été annulée ou reprogrammée. Qu’est-ce qui a motivé l’annulation ou le report de la maintenance ?

Il existe différents facteurs susceptibles d’entraîner l’annulation de la maintenance planifiée, notamment les actions suivantes :

• La suspension ou mise à l’échelle des opérations après réception d’une notification de maintenance en attente lors du lancement du cycle.
• Si vous ciblez différents objectifs de niveau de service (SLA) pendant le cycle de maintenance, par exemple en passant d’un SLO supérieur à DW400c, puis vous effectuez un scale-back vers un SLO inférieur ou égal à DW400c, ou vice versa, une annulation peut se produire. Cela est dû au fait que les fenêtres de maintenance ne s’appliquent pas aux niveaux de performances DW400c ou inférieurs, et qu’ils peuvent subir une maintenance à tout moment.
• Les facteurs d’infrastructure internes, tels que les modifications réelles apportées à la planification de la maintenance planifiée par l’équipe de mise en production.
• La maintenance peut être annulée ou replanifiée si la surveillance interne détecte que la maintenance prend plus de temps que prévu. La maintenance doit être effectuée dans les contrats de niveau de service (SLA) définis par les paramètres de fenêtre de maintenance du client.

Existe-t-il des bonnes pratiques à prendre en compte pour notre charge de travail pendant la fenêtre de maintenance ?

• Oui, si possible, suspendre toutes les charges de travail transactionnelles et ETL pendant l’intervalle de maintenance planifié pour éviter les erreurs ou les retards de restauration du service en ligne. Les opérations transactionnelles de longue durée doivent être effectuées avant une période de maintenance à venir.
• Pour que les charges de travail résistent aux interruptions provoquées par les opérations de maintenance, utilisez la logique de nouvelle tentative pour les niveaux de connexion et de commande (requête), en appliquant des intervalles de nouvelles tentatives plus longs et/ou plus de tentatives afin de résister à une perte de connexion étendue pouvant s’étendre jusqu’à 30 minutes dans certains cas.

Étapes suivantes

• En savoir plus sur la création, l’affichage et la gestion des alertes à l’aide d’Azure Monitor.
• En savoir plus sur les actions webhook pour les règles d’alerte de journal.
• En savoir plus sur la création et la gestion de groupes d’actions.
• En savoir plus sur Azure Service Health.