Un service,
une instance
Monter, mesurer, séparer, remesurer : le laboratoire de l'Application distribuée (Module 2).
420-5A4-MT · Acte 6 · La séparationCornucopia · Espace Membres & Commandes en Direct
Permettre à chaque membre de modifier son panier de légumes en temps réel : chaque clic génère une écriture ou une lecture personnalisée en base de données MySQL.
- Le cache Varnish ne peut pas intercepter les paniers personnalisés.
- La base de données et Apache se disputent le processeur de la même machine.
1 Million de requêtes BDD : séparer le Web et la BDD !
Sur le terrain
1 000 000 requêtes BDD / jour
MySQL consomme toute la mémoire RAM, provoquant des erreurs "Database Connection Error" pour les clients en ligne.
Rapport du terrain
Architecture tout-en-un incapable d'absorber la séparation des charges CPU (web) et I/O (BDD).
Isoler MySQL sur un serveur dédié, relier Apache via le réseau interne, et mesurer le gain avec un test de charge JMeter !
La mission du jour
À la fin de la séance, vous aurez :
- Partie 1 : WordPress et MySQL sur une seule instance, avec 2 articles illustrés dans un thème une page.
- Partie 2 : le même site avec chaque service sur son instance (mysql10, http20).
- Les deux montages mesurés au test de charge BRUTAL : captures top et tableau remplis.
- Le tout dans Git : /votre-depot/separation/
Cet atelier suit l'énoncé officiel Laboratoires Application distribuée (Module 2, 5 points, en équipe de 3 mais démonstration par étudiant). Minimum 2 commits pertinents en classe cette semaine.
WordPress et MySQL : une instance, puis deux
Partie 1 : tout sur une seule instance. Mettez en place, en fonction du matériel de cours, une instance unique qui héberge les deux services principaux :
- HTTP (apache2) : un WordPress avec au moins 2 articles (image et texte), présenté dans un thème qui tient en une seule page, accessible depuis le navigateur du système hôte.
- MySQL : la base de données du site.
Partie 2 : 1 service = 1 instance. Reconstruisez l'ensemble avec chaque service principal sur une instance distincte (mysql10, http20), selon la convention d'adressage.
Mesures (pour chaque partie) : test de charge BRUTAL avec JMeter :
- Une capture de la commande top en SSH de toutes les instances actives après environ 10 secondes de test : performances_partie_1_10secondes.png (puis partie_2, etc.).
- Une capture équivalente après environ 60 secondes : performances_partie_1_60secondes.png.
- Le tableau des performances rempli : valeur id (processeur inactif) de top pour chaque instance, et temps moyen de réponse indiqué par JMeter.
Barème : guide d'installation (2), fichiers de configuration (1), tableau rempli (1), captures d'écran (1).
Minimum 2 commits pertinents en classe durant la semaine 7; le reste avant le cours de la semaine 8. Ce laboratoire doit être entièrement terminé pour le début de la semaine 8.
WordPress et MySQL sur une seule VM
WordPress et MySQL sur une seule VM
La mise en place
- Mettre en place un ensemble de serveurs, en fonction du matériel de cours, ayant les caractéristiques suivantes :
- Chaque serveur provient d'une machine virtuelle de base nommée UbuntuServerAlpha.
- Système d'exploitation : Ubuntu Server, mémoire vive : 1 Gb, espace disque : 12 GB.
- hostname : SERVICE_PRINCIPAL + 3 derniers chiffres de l'IP (exemple : http20, mysql30...).
- Chaque service principal est sur la même machine virtuelle : HTTP (apache2) et MySQL.
- Un WordPress avec au moins 2 articles (image et texte) présenté dans un thème qui tient en une seule page.
- Permettant l'accès à l'URL hébergée sur le serveur virtuel via le navigateur du système hôte.
Le test de charge BRUTAL
- Faire un test de charge BRUTAL avec JMeter pour documenter les performances de votre ensemble de serveurs actuel.
- Faire une seule capture d'écran statique de la commande top exécutée en ssh de tous les serveurs actifs après environ 10 secondes de test (performances_partie_1_10secondes.png).
- La même chose après environ 60 secondes de test (performances_partie_1_60secondes.png).
- Noter dans un tableau la valeur idle du processeur (id) pour chaque serveur.
- Noter dans un tableau la valeur moyenne (temps moyen de réponse) indiquée par JMeter.
1 service = 1 serveur (VM)
1 service = 1 serveur (VM)
La mise en place
- Mettre en place un ensemble de serveurs, en fonction du matériel de cours, ayant les caractéristiques suivantes :
- Chaque serveur provient d'une machine virtuelle de base nommée UbuntuServerAlpha.
- Système d'exploitation : Ubuntu Server, mémoire vive : 1 Gb, espace disque : 12 GB.
- hostname : SERVICE_PRINCIPAL + 3 derniers chiffres de l'IP (exemple : http20, mysql30...).
- Chaque service principal est sur une machine virtuelle distincte : HTTP (apache2) et MySQL.
- Un WordPress avec au moins 2 articles (image et texte) présenté dans un thème qui tient en une seule page.
- Permettant l'accès à l'URL hébergée sur le serveur virtuel via le navigateur du système hôte.
Le test de charge BRUTAL
- Faire un test de charge BRUTAL avec JMeter pour documenter les performances de votre ensemble de serveurs actuel.
- Faire une seule capture d'écran statique de la commande top exécutée en ssh de tous les serveurs actifs après environ 10 secondes de test (performances_partie_2_10secondes.png).
- La même chose après environ 60 secondes de test (performances_partie_2_60secondes.png).
- Noter dans un tableau la valeur idle du processeur (id) pour chaque serveur.
- Noter dans un tableau la valeur moyenne (temps moyen de réponse) indiquée par JMeter.
Préparer ses instances
Selon votre choix d'infrastructure (VM VirtualBox, DinD ou VPS), préparez les instances de la semaine :
- Partie 1 : une instance tout-en-un (référence VirtualBox : 192.168.56.2, 1 Go, 12 Go).
- Partie 2 : deux instances, mysql10 et http20 (référence : 192.168.56.10 et .20).
- Convention de nommage : SERVICE_PRINCIPAL + 3 derniers chiffres de l'adresse (http20, mysql10).
- Continuité de la semaine 6 : votre varnish30 reste devant http20 - la base de données déménage DERRIÈRE le cache, et lui ne s'aperçoit de rien. Mesurez avec et sans cache pour voir les deux effets.
- Autre infra que VirtualBox : mêmes derniers chiffres dans votre sous-réseau, plan d'adressage documenté dans le README.
Tout sur une seule instance
- Installer les deux services principaux : HTTP (apache2) et MySQL, selon le matériel de cours.
- Un WordPress avec au moins 2 articles (image et texte), présenté dans un thème qui tient en une seule page.
- Le site doit répondre dans le navigateur de la machine hôte.
Vous avez déjà toutes les techniques : c'est le WordPress du cours de serveur, remonté proprement. Le but de cette partie n'est pas la nouveauté : c'est d'avoir un point de comparaison mesurable.
Premier test de charge BRUTAL
- Dans JMeter : un Thread Group bien gonflé, une requête HTTP vers la page d'accueil, la vue View Results in Table.
- Pendant le test, top en SSH sur toutes les instances actives.
- Capture après environ 10 secondes : performances_partie_1_10secondes.png
- Capture après environ 60 secondes : performances_partie_1_60secondes.png
- Noter au tableau : la valeur id de chaque instance et le temps moyen JMeter.
| secondes / serveur | WORDPRESS-MYSQL | temps moyen de réponse (seconde) |
|---|---|---|
| 10 secondes | ||
| 60 secondes |
Séparer : 1 service = 1 instance
Vérification : le site répond depuis l'hôte, les articles sont là. Si la page est blanche, les journaux d'Apache et l'utilisateur MySQL distant sont vos premiers suspects.
Remesurer, comparer, conclure
- Même test BRUTAL, mêmes techniques : captures performances_partie_2_10secondes.png et performances_partie_2_60secondes.png (top des DEUX instances cette fois).
- Remplir la deuxième ligne du tableau : id de mysql10, id de http20, temps moyen JMeter.
- La question d'architecte, à répondre dans votre guide : qu'est-ce qui s'est amélioré, qu'est-ce qui s'est dégradé, et pourquoi ?
| secondes / serveur | HTTP | MYSQL | temps moyen de réponse (seconde) |
|---|---|---|---|
| 10 secondes | |||
| 60 secondes |
WordPress et MySQL sur une seule VM
1 service = 1 serveur (VM)
- (2 points) sa version de son guide d'installation
- (1 point) les fichiers de configurations utilisés
- (1 point) le tableau rempli
- (1 point) les captures d'écran
Un minimum de 2 commits pertinents doit être effectué en classe durant la semaine 1, les autres devant être complétés avant le cours de la semaine 2. Ce laboratoire doit être entièrement terminé pour le début de la semaine 2.
Livrables et devoir
- Dans Git : votre guide d'installation .md, les fichiers de configuration, le tableau rempli, les captures. Pour chaque étudiant.
- Les instances restent fonctionnelles : elles servent de base à toute la suite du module.
- Devoir : terminer le laboratoire avant le cours de la semaine 8.
La semaine prochaine, l'acte 7 : tout passe par une seule entrée, un seul chemin. On double tout - deux Varnish, deux HAProxy, une IP virtuelle - et on éteindra le maître en pleine charge pour voir le site survivre.