Configurer et superviser la disponibilité

Effectué

Maintenant que vous connaissez toutes les possibilités, vous allez devoir créer une stratégie pour la charge de travail spécifique dont votre base de données Azure SQL ou votre instance gérée Azure SQL fait partie.

Faire les bons choix

Une grande part de ce processus de création d’une stratégie consiste à prendre du recul et à réfléchir aux exigences de votre charge de travail. Voici quelques questions à considérer :

  • Avez-vous besoin de sauvegardes à long terme ? Ou est-ce que qu’une durée de 1 à 35 jours est suffisante ?
  • Quels sont vos besoins en RTO et RPO ?
  • En fonction du contrat SLA, quel est le niveau de service le plus approprié ?
  • Avez-vous besoin de zones de disponibilité ?
  • Avez-vous besoin de HADR géorépliqué ou de groupes de basculement ?
  • Votre application est-elle prête ?

Les réponses à ces questions vous aideront à déterminer la configuration que vous devez déployer pour répondre à vos exigences en matière de disponibilité.

La dernière question est souvent négligée par le professionnel des données : Votre application est-elle prête ? Ce point est crucial pour obtenir le contrat SLA que vous souhaitez.

Vous devez vous assurer que votre base de données répond à vos besoins en disponibilité, mais également votre application. Vous devez aussi vous assurer que la connectivité entre les données et les applications répond à vos exigences. Par exemple, si votre application et votre base de données se trouvent dans des régions différentes, cet emplacement augmentera la latence réseau. Placez votre application et vos données le plus près possible les unes des autres. Tout au long de ce module, vous avez également appris l’importance de l’implémentation d’une logique de nouvelle tentative dans vos applications pour préserver la disponibilité.

Analyser la disponibilité

Azure SQL fournit plusieurs outils et fonctionnalités permettant d’analyser certains aspects de la disponibilité. Ces outils incluent le Portail Azure, T-SQL et les interfaces comme PowerShell, az CLI et les API REST.

Les sections suivantes décrivent certains exemples d’utilisation de ces outils pour analyser la disponibilité.

Disponibilité des régions et des centres de données

La disponibilité des régions et des centres de données est essentielle pour la disponibilité du déploiement d’une instance gérée ou d’une base de données. État d’Azure et Azure Service Health sont essentiels pour comprendre les interruptions d’un centre de données ou d’une région, notamment des services spécifiques comme Azure SQL.

L’état Azure est un tableau de bord qui présente les services qui entraînent des problèmes dans n’importe quelle région globale Azure. Vous pouvez utiliser un flux RSS pour recevoir des notifications concernant les modifications apportées à l’état Azure.

Vous pouvez consulter Azure Service Health dans le Portail Azure. Azure Service Health fournit des informations sur les problèmes de service, les événements de maintenance planifiée, les avis d’intégrité et l’historique d’intégrité. Vous avez également la possibilité de configurer des alertes pour être notifié par e-mail ou par SMS de tout événement susceptible d’affecter la disponibilité.

Disponibilité des instances, des serveurs et des bases de données

En plus des événements de services Azure, vous pouvez consulter la disponibilité d’Azure SQL Managed Instance ou des bases de données Azure SQL Database via le Portail Azure.

Un des moyens de consulter la raison possible pour laquelle une instance gérée ou une base de données n’est pas disponible est d’examiner l’intégrité des ressources via le Portail Azure ou les API REST.

Vous pouvez toujours utiliser des outils SQL Server standard, comme SQL Server Management Studio (SSMS), pour vous connecter à une instance gérée ou à un serveur de bases de données et vérifier l’état de ces ressources. Vous pouvez utiliser l’outil ou les requêtes T-SQL.

Des interfaces comme Azure CLI peuvent afficher l’état d’Azure SQL. Par exemple :

  • az sql mi list répertorie l’état des instances gérées.
  • az sql db list répertorie l’état des bases de données Azure SQL.

Vous pouvez également utiliser des commandes PowerShell pour indiquer la disponibilité d’une base de données Azure SQL. Par exemple :

  • Get-AzSQLDatabase obtient toutes les bases de données sur un serveur et leurs détails, notamment leur état.
  • Les API REST ne sont pas aussi faciles à utiliser, mais vous pouvez les utiliser pour obtenir l’état des instances gérées et des bases de données.

Historique des sauvegardes et des restaurations

Azure SQL sauvegarde automatiquement les bases de données et les journaux des transactions. L’historique des sauvegardes standard n’est pas disponible, mais vous pouvez afficher l’historique de conservation des données de sauvegarde à long terme via le Portail Azure ou les interfaces CLI. En outre, dans Azure SQL Managed Instance, vous pouvez utiliser XEvents pour effectuer le suivi de l’historique des sauvegardes.

Toute restauration de base de données qui utilise la limite de restauration dans le temps crée une nouvelle base de données. Vous pouvez utiliser le journal d’activité Azure pour afficher les opérations de création de bases de données.

État des réplicas

Les réplicas sont utilisés pour les niveaux de service « Critique pour l’entreprise ». Vous pouvez afficher l’état d’un réplica à l’aide de la vue de gestion dynamique sys.dm_database_replica_states.

Causes du basculement

Pour déterminer la cause d’un événement de basculement pour un déploiement d’Azure SQL Managed Instance ou d’une base de données, consultez l’intégrité des ressources via le Portail Azure ou les API REST.

Pack d’administration System Center pour Azure SQL

System Center fournit des packs d’administration pour superviser Azure SQL Managed Instance et Azure SQL Database. Consultez la documentation sur le pack d’administration pour vérifier les détails et exigences.

Contrôle des connaissances

1.

Quelles méthodes pouvez-vous utiliser pour analyser la disponibilité d’une région et d’un centre de données ?

2.

Parmi les outils suivants, lequel ne permet pas d’analyser la disponibilité des instances, des serveurs et des bases de données ?