Exercice : Protéger, surveiller et régler une base de données migrée

  • 20 minutes

Vous travaillez en tant que développeur de base de données pour l’organisation AdventureWorks. AdventureWorks vend des vélos et des pièces de vélos directement aux consommateurs finaux et aux distributeurs depuis plus de dix ans. Ses systèmes stockent des informations dans une base de données que vous avez précédemment migrées vers Azure Database pour PostgreSQL.

Une fois la migration effectuée, vous devez vous assurer que le système fonctionne correctement. Vous décidez d’utiliser les outils Azure disponibles pour surveiller le serveur. Pour réduire le risque de temps de réponse lents dus à la contention et à la latence, vous décidez d’implémenter la réplication de lecture. Vous devez surveiller le système obtenu et comparer les résultats avec l’architecture du serveur flexible.

Dans cet exercice, vous allez effectuer les tâches suivantes :

  1. Configurer les métriques Azure pour votre service Azure Database pour PostgreSQL.
  2. Exécuter un exemple d’application qui simule plusieurs utilisateurs interrogeant la base de données.
  3. Afficher les métriques.

Configurer l’environnement

Exécutez ces commandes Azure CLI dans le Cloud Shell pour créer une base de données Azure pour PostgreSQL, avec une copie de la base de données adventureworks. Les dernières commandes indiqueront le nom du serveur.

SERVERNAME="adventureworks$((10000 + RANDOM % 99999))"
PUBLICIP=$(wget http://ipecho.net/plain -O - -q)
git clone https://github.com/MicrosoftLearning/DP-070-Migrate-Open-Source-Workloads-to-Azure.git workshop

az postgres server create \
    --resource-group <rgn>[sandbox resource group name]</rgn> \
    --name $SERVERNAME \
    --location westus \
    --admin-user awadmin \
    --admin-password Pa55w.rdDemo \
    --version 10 \
    --storage-size 5120

az postgres db create \
    --name azureadventureworks \
    --server-name $SERVERNAME \
    --resource-group <rgn>[sandbox resource group name]</rgn>

az postgres server firewall-rule create \
    --resource-group <rgn>[sandbox resource group name]</rgn> \
    --server $SERVERNAME \
    --name AllowMyIP \
    --start-ip-address $PUBLICIP --end-ip-address $PUBLICIP

PGPASSWORD=Pa55w.rdDemo psql -h $SERVERNAME.postgres.database.azure.com -U awadmin@$SERVERNAME -d postgres -f workshop/migration_samples/setup/postgresql/adventureworks/create_user.sql

PGPASSWORD=Pa55w.rd psql -h $SERVERNAME.postgres.database.azure.com -U azureuser@$SERVERNAME -d azureadventureworks -f workshop/migration_samples/setup/postgresql/adventureworks/adventureworks.sql 2> /dev/null

echo "Your PostgreSQL server name is:\n"
echo $SERVERNAME.postgres.database.azure.com

Configurer les métriques Azure pour votre service Azure Database pour PostgreSQL

  1. À l’aide d’un navigateur Web, ouvrez un nouvel onglet et accédez au Portail Azure.

  2. Dans le portail Azure, sélectionnez Toutes les ressources.

  3. Sélectionnez le nom du serveur Azure Database pour PostgreSQL commençant par adventureworks.

  4. Sous Supervision, sélectionnez Métriques.

  5. Sur la page du graphique, ajoutez la métrique suivante :

    Propriété Valeur
    Étendue adventureworks[nnn]
    Espace de noms de métrique Métriques standard du serveur PostgreSQL
    Métrique Connexions actives
    Agrégation Avg

    Cette métrique affiche le nombre moyen de connexions au serveur chaque minute.

  6. Sélectionnez Ajouter une métrique, puis ajoutez la métrique suivante :

    Propriété Valeur
    Étendue adventureworks[nnn]
    Espace de noms de métrique Métriques standard du serveur PostgreSQL
    Métrique Pourcentage d’UC
    Agrégation Avg

  7. Sélectionnez Ajouter une métrique, puis ajoutez la métrique suivante :

    Propriété Valeur
    Étendue adventureworks[nnn]
    Espace de noms de métrique Métriques standard du serveur PostgreSQL
    Métrique Pourcentage de mémoire
    Agrégation Avg

  8. Sélectionnez Ajouter une métrique, puis ajoutez la métrique suivante :

    Propriété Valeur
    Étendue adventureworks[nnn]
    Espace de noms de métrique Métriques standard du serveur PostgreSQL
    Métrique Pourcentage d’E/S
    Agrégation Avg

    Ces trois dernières métriques montrent comment les ressources sont consommées par l’application de test.

  9. Définissez l’intervalle de temps du graphique sur 30 dernières minutes.

  10. Sélectionnez Épingler au tableau de bord, puis sélectionnez Épingler.

Exécuter un exemple d’application qui simule plusieurs utilisateurs interrogeant la base de données

  1. Dans le portail Azure, sur la page de votre serveur Azure Database pour PostgreSQL, sous Paramètres, sélectionnez Chaînes de connexion. Copiez la chaîne de connexion ADO.NET dans le Presse-papiers.

  2. Accédez au dossier ~/workshop/migration_samples/code/postgresql/AdventureWorksSoakTest.

    cd ~/workshop/migration_samples/code/postgresql/AdventureWorksSoakTest

  3. Ouvrez le fichier App.config à l’aide de l’éditeur de code :

    code App.config

  4. Remplacez la valeur de Base de données par azureadventureworkset remplacez ConectionString0 par la chaîne de connexion dans le presse-papiers. Changez l’identifiant utilisateur en azureuser@adventureworks[nnn], puis affectez à Password la valeur Pa55w.rd. Le fichier terminé doit ressembler à l’exemple ci-dessous :

    <?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <appSettings>
        <add key="ConnectionString0" value="Server=adventureworks101.postgres.database.azure.com;Database=azureadventureworks;Port=5432;User Id=azureuser@adventureworks101;Password=Pa55w.rd;Ssl Mode=Require;" />
        <add key="ConnectionString1" value="INSERT CONNECTION STRING HERE" />
        <add key="ConnectionString2" value="INSERT CONNECTION STRING HERE" />
        <add key="NumClients" value="100" />
        <add key="NumReplicas" value="1"/>
    </appSettings>
</configuration>

    Notes

    Ignorez les paramètres ConnectionString1 et ConnectionString2 pour le moment. Vous mettrez ces éléments à jour plus tard dans le laboratoire.

  5. Enregistrez les modifications et fermez l'éditeur.

  6. À l’invite Cloud Shell, exécutez la commande suivante pour générer et exécuter l’application :

    dotnet run

    Lorsque l’application démarre, elle génère un nombre de threads, chaque thread simulant un utilisateur. Les threads forment une boucle en exécutant une série de requêtes. Vous verrez que des messages tels que ceux ci-dessous commencent à s’afficher :

    Client 48 : SELECT * FROM purchasing.vendor
Response time: 630 ms

Client 48 : SELECT * FROM sales.specialoffer
Response time: 702 ms

Client 43 : SELECT * FROM purchasing.vendor
Response time: 190 ms

Client 57 : SELECT * FROM sales.salesorderdetail
Client 68 : SELECT * FROM production.vproductanddescription
Response time: 51960 ms

Client 55 : SELECT * FROM production.vproductanddescription
Response time: 160212 ms

Client 59 : SELECT * FROM person.person
Response time: 186026 ms

Response time: 2191 ms

Client 37 : SELECT * FROM person.person
Response time: 168710 ms

    Laissez l’application s’exécuter pendant que vous effectuez les étapes suivantes.

Afficher les métriques

  1. Revenez au portail Azure.

  2. Dans le volet à gauche, sélectionnez Tableau de bord.

    Le graphique doit afficher les métriques de votre service Azure Database pour PostgreSQL.

  3. Sélectionnez le graphique pour l’ouvrir dans le volet Métriques.

  4. Laissez l’application s’exécuter pendant plusieurs minutes (le plus longtemps possible). À mesure que le temps passe, les métriques du graphique doivent ressembler au modèle illustré dans l’image suivante :

    Image showing the metrics gathered while the sample app is running

    Ce graphique met en évidence les points suivants :

    • L’UC s’exécute à pleine capacité ; l’utilisation atteint 100 % très rapidement.
    • Le nombre de connexions augmente lentement. L’exemple d’application est conçu pour démarrer 101 clients successivement, mais le serveur ne peut ouvrir que quelques connexions à la fois. Le nombre de connexions ajoutées à chaque « étape » dans le graphique diminue et le délai entre les « étapes » augmente. Après environ 45 minutes, le système n’a pu établir que 70 connexions clients.
    • L’utilisation de la mémoire augmente de manière cohérente dans le temps.
    • L’utilisation d’E/S est proche de zéro. Toutes les données requises par les applications clientes sont actuellement mises en cache en mémoire.

    Si vous laissez l’application s’exécuter suffisamment longtemps, vous verrez que les connexions commencent à échouer, avec les messages d’erreur indiqués dans l’image suivante.

    Image showing the connection errors that can occur when the server has insufficient resources available

  5. Dans le Cloud Shell, appuyez sur Entrée pour arrêter l’application.

Configurer le serveur pour collecter les données de performances des requêtes

  1. Dans le portail Azure, sur la page de votre serveur Azure Database pour PostgreSQL, sous Paramètres, sélectionnez Paramètres du serveur.

  2. Sur la page Paramètres du serveur, définissez les paramètres suivants sur les valeurs spécifiées dans le tableau ci-dessous.

    Paramètre Value
    pg_qs.max_query_text_length 6000
    pg_qs.query_capture_mode ALL
    pg_qs.replace_parameter_placeholders ON
    pg_qs.retention_period_in_days 7
    pg_qs.track_utility ON
    pg_stat_statements.track ALL
    pgms_wait_sampling.history_period 100
    pgms_wait_sampling.query_capture_mode ALL

  3. Sélectionnez Enregistrer.

Examiner les requêtes exécutées par l’application à l’aide de Magasin des requêtes

  1. Revenez au Cloud Shell et redémarrez l’exemple d’application :

    dotnet run

    Laissez l’application s’exécuter pendant 5 minutes environ avant de continuer.

  2. Laissez l’application s’exécuter et basculez vers le portail Azure.

  3. Sur la page de votre serveur Azure Database pour PostgreSQL, sous Performances intelligentes, sélectionnez Aperçu des performances de requête.

  4. Sur la page Aperçu des performances de requête, sous l’onglet Requêtes longues, définissez Nombre de requêtes sur 10, définissez Sélectionné par sur Moy et définissez la Période sur 6 dernières heures.

  5. Au-dessus du graphique, sélectionnez plusieurs fois Zoom avant (l’icône de loupe avec le signe « + ») pour obtenir les données les plus récentes.

    En fonction de la durée d’exécution de l’application, un graphique semblable à celui ci-dessous s’affiche. Magasin des requêtes agrège les statistiques des requêtes toutes les 15 minutes, chaque barre affiche donc le temps relatif consommé par chaque requête pendant chaque période de 15 minutes :

    Image showing the statistics for long running queries captured by using Query Store

  6. Placez le curseur de la souris sur chaque barre pour afficher les statistiques des requêtes pendant cette période. Les trois requêtes dont la durée d’exécution est la plus longue sur le système sont les suivantes :

    SELECT * FROM sales.salesorderdetail
SELECT * FROM sales.salesorderheader
SELECT * FROM person.person

    Ces informations sont utiles pour un administrateur surveillant un système. Disposer d’un aperçu des requêtes exécutées par les utilisateurs et les applications vous permet de comprendre les charges de travail exécutées et éventuellement de faire des recommandations aux développeurs d’applications sur les améliorations qu’ils peuvent apporter à leur code. Par exemple, est-il vraiment nécessaire qu’une application récupère les plus de lignes 121 000 de la table sales.salesorderdetail ?

Examiner les attentes qui se produisent avec Magasin des requêtes

  1. Sélectionnez l’onglet Statistiques d’attente.

  2. Définissez la Période sur 6 dernières heures, définissez Regrouper par sur Événement et définissez le Nombre maximal de groupes sur 5.

    Comme avec l’onglet Requêtes longues, les données sont agrégées toutes les 15 minutes. Le tableau sous le graphique montre que le système a rencontré deux types d’événements d’attente :

    • Client : ClientWrite. Cet événement d’attente se produit lorsque le serveur écrit des données (résultats) sur le client. Il n’indique pas les attentes qui se sont produites lors de l’écriture dans la base de données.
    • Client : ClientRead. Cet événement d’attente se produit lorsque le serveur attend de lire des données (requêtes ou autres commandes) à partir d’un client. Il n’est pas associé au temps passé à lire à partir de la base de données.

    Image showing the wait statistics captured by using Query Store

    Remarque

    Les lectures et écritures dans la base de données sont indiquées par les événements E/S plutôt que par les événements Client. L’exemple d’application n’entraîne pas d’attente d’E/S, car toutes les données requises sont mises en cache dans la mémoire après la première lecture. Si les métriques indiquaient que la mémoire s’amenuisait, vous verrez probablement que des événements d’attente d’E/S commencent à se produire.

  3. Revenez au Cloud Shell, puis appuyez sur Entrée pour arrêter l’exemple d’application.

Ajouter des réplicas au service Azure Database pour PostgreSQL

  1. Dans le portail Azure, sur la page de votre serveur Azure Database pour PostgreSQL, sous Paramètres, sélectionnez Réplication.

  2. Sur la page Réplication, sélectionnez + Ajouter un réplica.

  3. Sur la page Serveur PostgreSQL, dans la zone Nom du serveur, tapez adventureworks[nnn]-replica1, puis sélectionnez OK.

  4. Une fois le premier réplica créé (plusieurs minutes peuvent être nécessaires), répétez l’étape précédente et ajoutez un autre réplica nommé adventureworks[nnn]-replica2.

  5. Attendez que l’état des deux réplicas passe de Déploiement à Disponible avant de continuer.

    Image showing the Replication page for Azure Database for PostgreSQL. Two replicas have been added.

Configurer les réplicas pour autoriser l’accès client

  1. Sélectionnez le nom du réplica adventureworks[nnn]-replica1. Vous êtes dirigé vers la page d’Azure Database pour PostgreSQL pour ce réplica.
  2. Sous Paramètres, sélectionnez Sécurité de la connexion.
  3. Sur la page Sécurité de la connexion, activez Autoriser l’accès aux services Azure (ON), puis sélectionnez Enregistrer. Ce paramètre permet aux applications que vous exécutez à l’aide du Cloud Shell d’accéder au serveur.
  4. Une fois le paramètre enregistré, répétez les étapes précédentes et autorisez les services Azure à accéder au réplica adventureworks[nnn]-replica2.

Redémarrer chaque serveur

Notes

La configuration de la réplication ne nécessite pas le redémarrage d’un serveur. L’objectif de cette tâche est d’effacer la mémoire et toutes les connexions superflues à partir de chaque serveur, afin que les métriques recueillies lors de l’exécution de l’application soient de nouveau propres.

  1. Accédez à la page du serveur adventureworks[nnn].
  2. Sur la page Vue d’ensemble, sélectionnez Redémarrer.
  3. Dans la boîte de dialogue Redémarrer le serveur, sélectionnez Oui.
  4. Attendez que le serveur ait redémarré avant de continuer.
  5. Suivez la même procédure, redémarrez les serveurs adventureworks[nnn]-replica1 et adventureworks[nnn]-replica2.

Reconfigurer l’exemple d’application pour utiliser les réplicas

  1. Dans le Cloud Shell, modifiez le fichier App.config.

    code App.config

  2. Ajoutez les chaînes de connexion pour les paramètres ConnectionString1 et ConnectionString2. Ces valeurs doivent être les mêmes que celles de ConnectionString0, mais où le texte adventureworks [nnn] est remplacé par adventureworks[nnn]-replica1 et adventureworks[nnn]-Replica2 dans les éléments Serveur et ID utilisateur.

  3. Définissez le paramètre NumReplicas sur 3.

    Le fichier App.config doit maintenant ressembler à ceci :

    <configuration>
    <appSettings>
        <add key="ConnectionString0" value="Server=adventureworks101.postgres.database.azure.com;Database=azureadventureworks;Port=5432;User Id=azureuser@adventureworks101;Password=Pa55w.rd;Ssl Mode=Require;" />
        <add key="ConnectionString1" value="Server=adventureworks101-replica1.postgres.database.azure.com;Database=azureadventureworks;Port=5432;User Id=azureuser@adventureworks101-replica1;Password=Pa55w.rd;Ssl Mode=Require;" />
        <add key="ConnectionString2" value="Server=adventureworks101-replica2.postgres.database.azure.com;Database=azureadventureworks;Port=5432;User Id=azureuser@adventureworks101-replica2;Password=Pa55w.rd;Ssl Mode=Require;" />
        <add key="NumClients" value="100" />
        <add key="NumReplicas" value="3"/>
    </appSettings>
</configuration>

  4. Enregistrez le fichier et fermez l’éditeur.

  5. Démarrez à nouveau l’application en cours d’exécution  :

    dotnet run

    L’application s’exécute comme avant. Toutefois, cette fois-ci, les requêtes sont réparties sur les trois serveurs.

  6. Laissez l’application s’exécuter pendant quelques minutes avant de continuer.

Surveiller l’application et observer les différences dans les métriques de performances

  1. Laissez l’application s’exécuter et revenez au portail Azure.

  2. Dans le volet à gauche, sélectionnez Tableau de bord.

  3. Sélectionnez le graphique pour l’ouvrir dans le volet Métriques.

    N’oubliez pas que ce graphique affiche les métriques du serveur adventureworks*[nnn]*, mais pas les réplicas. La charge de chaque réplica doit être très similaire.

    L’exemple de graphique illustre les métriques recueillies pour l’application sur une période de 30 minutes, depuis le démarrage. Le graphique montre que l’utilisation de l’UC est toujours élevée, mais que l’utilisation de la mémoire était inférieure. En outre, après environ 25 minutes, le système avait établi des connexions pour plus de 30 connexions. Cela peut ne pas sembler une comparaison favorable à la configuration précédente, qui prenait en charge 70 connexions après 45 minutes. Toutefois, la charge de travail a été répartie sur trois serveurs, qui étaient tous exécutés au même niveau, et l’ensemble des 101 connexions ont été établies. En outre, le système a pu s’exécuter sans signaler d’échecs de connexion.

    Image showing the metrics for the Azure Database for PostgreSQL server while running the application, after replication was configured

    Vous pouvez résoudre le problème d’utilisation d’UC en mettant à l’échelle un niveau tarifaire supérieur avec davantage de cœurs d’UC. L’exemple de système utilisé dans ce laboratoire s’exécute à l’aide du niveau tarifaire De base avec 2 cœurs. Le passage au niveau tarifaire Usage général vous donnera jusqu’à 64 cœurs.

  4. Revenez au Cloud Shell, puis appuyez sur Entrée pour arrêter l’application.

Vous avez maintenant vu comment surveiller l’activité du serveur à l’aide des outils disponibles dans le portail Azure. Vous avez également appris à configurer la réplication et vu comment la création de réplicas en lecture seule peut répartir la charge de travail dans des scénarios de données nécessitant beaucoup de lectures.