Master 2, Bases de données avancées, année 2022

Objectif

Se familiariser avec la plateforme OpenStack.
Installer PostgreSQL depuis les dépôts sur plusieurs VM et configurer les accès distants.
Réaliser un microbenchmarque sur OpenStack pour avoir une idée des performances de PostgreSQL dans cet environnement.
Mettre en place un mécanisme de distribution des données Primary/Replica (Optionnel)
Mettre en place un mécanisme de distribution des données via les FDW (Peut être)

Utilisation d’OpenStack

Connectez vous à openstack et créez une instance Ubuntu avec le moins de ressources possibles. On utilisera éventuellement les ressources disponibles lors d’autres TP.

La plateforme est utilisable depuis chez vous en utilisant le VPN étudiant.

Pour cela Suivez le tutoriel présent sur la plateforme. Configurez votre console local pour pouvoir vous connecter en ssh. Pour une instance ubuntu avec les clefs ssh configurées correctement il suffit de faire: ssh ubuntu@[adresse-ip] où adresse-ip est l’adresse indiquée par la plateforme.

Créez vous un compte personnel sur cette machine avec un nom de votre choix et configurez-vous un accès ssh par clef. Dans la suite du TP, ce compte personnel sera noté $remote.
Créez un compte personnel cha pour moi sur cette machine avec la clef publique trouvable ici.

N’utilisez pas $remote comme nom d’utilisateur, le $ va vous embêtez. Utilisez un nom facile à retenir et simple. J’utilise par exemple cha pour mes machines. (N’utilisez pas cha non plus, c’est déjà pris).

Ajoutez dans le fichier de rendu l’adresse IP de toutes vos VM qui seront crées durant le TP.

Installation et configuration des accès au serveur PostgreSQL

Installez PostgreSQL depuis les dépôts et vérifiez que vous pouvez vous y connecter via l’invité de commande psql avec l’utilisateur $remote.

Pour ce faire, vous pouvez vous connecter à la base de donnée en tant qu’utilisateur postgres et ajouter l’utilisateur $remote. Vous pouvez également créer une base de nommée $remote, afin de permettre la connexion sans avoir à préciser une base de données existante.

Donnez à l’utilisateur de la base de donnée $remote le droit administrateur (superuser).

Pour ce faire, vous pouvez vous connecter à la base de donnée en tant qu’utilisateur postgres et ajouter le droit SUPERUSER.

À l’aide de la documentation du fichier de configuration pg_hba.conf, donnez les droits de connexions sécurisés (par mot de passes) à PostgreSQL depuis des machines distantes pour l’utilisateur $remote. Vérifier que vous pouvez bien vous connectez à distance depuis votre machine locale.

Les chemins d’accès des fichiers de configuration postgresql.conf et pg_hba.conf peuvent être obtenus facilement depuis psql via les commandes SHOW config_file et SHOW hba_file.

Vous devez aussi modifier le fichier postgresql.conf pour autoriser PostgreSQL à écouter sur toutes les adresses.

Refaites les manipulations avec l’utilisateur cha et le mot de passe de connexion ILovePostgreSQL. N’oubliez pas de le rendre administrateur également.

Une application de micro-blogging

Nous allons créer une petite application de micro-blogging (un peu comme Twitter) en utilisant PostgreSQL. Vous pouvez télécharger le schéma SQL ici.

Créez une base de données microblog avec votre utilisateur et exécutez dans cette base de données le contenu du fichier microblog.sql.

Pour exécuter le fichier, vous pouvez simplement l’envoyer sur l’entrée standard de psql:

cat microblog.sql | psql -h $remoteip -U $remote --dbname microblog

Lisez le fichier microblog.sql et expliquez brièvement les différentes fonctionnalité de cette base de données.
Est-ce qu’il est possible pour l’utilisateur common_user:

de récupérer la totalité des messages publiés
de récupérer la liste des utilisateurs inscrits
de récupérer le mot de passe d’un utilisateur inscrit

Est-il possible pour l’utilisateur possédant la base de données

de récupérer la totalité des messages publiés
de récupérer la liste des utilisateurs inscrits
de récupérer le mot de passe d’un utilisateur inscrit

A quoi sert la ligne:

CLUSTER messages_store USING idx_pub_date;

(Optionnelle, difficile) Proposez une nouvelle fonction qui permette de récupérer pour chaque uuid de la base de donnée un document JSON contenant les données associée. Par exemple, ça retournera pour un utilisateur son nom et ses 10 derniers message et pour un message, son auteur et sa date de publication, son contenu et les autres informations pertinentes.

Vous pouvez utiliser pour ça les fonctions json_build_object

Modifier la configuration de PostgreSQL pour autoriser l’utilisateur common_user à ce connecter (sans mot de passe)

Des robots pour le Benchmarking

Nous allons maintenant réaliser un benchmarking simple pour mesurer les performances du microblog. Pour ce faire, nous allons simuler des utilisateurs qui utilisent l’API exposé par la base de données.

En en utilisant(ou adaptant) du fichier api_microblog.py dans le langage de votre choix, écrivez un programme qui simule le comportement d’utilisateurs factices sur le blog. (Version java)

Il est important de garder le programme monothread (monoprocessus) et de maintenir les connexions à la BDD ouverte.

Vous pouvez générer des utilisateurs factices avec un mot de passe aléatoire à l’aide du programme rig et du scripte suivant:

for i in $(seq 0 1000); do
    rig | head -n1 >> names # generate random names
    head -c 100 /dev/urandom | md5sum | cut -f1 -d " " >> pass # generate random passwords
done
paste names pass > users
rm names pass
OLDIFS="$IFS" # Sauvegarde la variable d'environement $IFS. (Voire help read)
IFS=$(echo -e '\t') # Choisi les tabulation comme séparateur.
while read name password;
do
    echo "SELECT create_user('$name', '$password')" | psql -d microblog -U common_user -h $remote_ip -t > /dev/null &
done < users
IFS="$OLDIFS"
wait $(jobs -p)
echo "#Done#

Indiquer le nombre de transactions par secondes (TPS) en fonction du nombre de processus que vous lancez depuis votre machine. Vous pouvez également utiliser plusieurs machine pour pousser le serveur Postgres à sa limite.

Attention, cette partie dépend fortement du réseau.
Vous pouvez monitorer le serveur PostgreSQL à l’aide du logiciel cli pg_activity qui donne le nombre de transaction par seconde.

Redimensionnez votre instance OpenStack pour ajouter des ressources de calculs, et comparer les résultats obtenus

Les VM openstack ne saturent pas encore la bande passante du disque dure physique. Le goulot d’étranglement reste les capacités calculatoire. Sur une machine physique avec un disque dure dédiés et une plus de coeurs on aurait de meilleurs performances (en TPS) mais augmenter le nombre de processeur ne marcherait que jusqu’à saturation du disque.

PostgreSQL et la disponibilité (difficile)

Afin de garantir qu’une base de données reste disponible, il est possible de configurer plusieurs serveur PostgreSQL pour travailler ensemble.

Créer une nouvelle VM avec PostgreSQL installé.

Dans la suite on nomme la première machine $primary et la seconde $replica et leurs IP $primary_ip et la seconde $replica_ip.

Modifiez sur la VM primaire l’option de postgresql.conf:

wal_level=logical

Cette option permet d’ajuster le niveau des Write Ahead Log pour permettre la réplication logique.

On va créer une replication logique de la base de données primaire sur la secondaire. Pour ce faire:

lisez la page d’introduction sur la replication logique
lisez la page sur la publication
lisez la page sur la sucription

Créez une publication dans la base de donnée primaire pour toute les tables et une souscription dans la base de donnée secondaire.
Vérifiez que cette dernière fonctionne bien en envoyant un message sur la base de donnée primaire et en requêtant la base de donnée secondaire.
D’après vous, où ce situe cette solution par rapport au Théorème CAP vu en cours?

Compiled the: dim. 07 janv. 2024 23:19:08 CET

À lire avant de commencer