Le cluster
Raspberry Pi

Assembler un vrai centre de données de bureau et y faire tourner l'architecture : le laboratoire 4 de l'Application distribuée.

À la fin de la séance, l'équipe aura :

• Assemblé et préparé ses Raspberry Pi (disques M2, image, noms).
• Installé l'ensemble des services testés précédemment sur la grappe, à l'aide du meilleur guide de l'équipe.
• Rédigé un nouveau guide d'installation avec les modifications nécessaires au matériel réel.
• Mesuré au test de charge BRUTAL et affiché WordPress dans un navigateur : la démonstration qui donne les points.
• GitHub : /laboratoire4/ · un PDF unique pour l'équipe.

En équipe, mais chaque membre doit commettre des contributions significatives au nouveau guide : sans commits significatifs, pas de points pour ce membre. Minimum 4 commits d'équipe en classe (au moins 1 par étudiant).

Préparer le démarrage USB

• Avec Raspberry Pi Imager, écrire l'image utilitaire Bootloader - USB Boot sur une carte micro SD de service.
• Insérer la carte dans chaque Pi, allumer, attendre le voyant vert constant (ou l'écran vert), éteindre, retirer.
• Cette carte se réutilise : un seul passage par Pi, et le Pi démarre désormais sur USB.

Pendant ce temps, le reste de l'équipe assemble : disque M2 sur son adaptateur USB, adaptateur sur l'extenseur. Chaîne de montage : chacun son poste.

Écrire le système sur les disques M2

• Raspberry Pi Imager : Raspberry Pi OS Lite (64-bit), destination : le disque M2 branché en USB.
• Dans les options (l'écrou) : nom d'hôte pi1 à pi8 selon la séquence, usager pi, mot de passe d'équipe, SSH activé.
• Vérifier deux fois le lecteur de destination avant d'écrire : l'Imager efface sans remords.

Câbler, démarrer, vérifier

• Chaque Pi reçoit son disque, son câble réseau vers le commutateur, son alimentation.
• Relever les adresses, compléter le plan d'adressage de l'équipe : quel Pi porte quel rôle (base, web, caches, balanceurs).
• Vérification d'usage : SSH sur chaque noeud, ping entre les noeuds.

Rejouer le meilleur guide de l'équipe

• Choisir le meilleur guide d'installation parmi ceux des membres : c'est lui, le plan de match.
• Installer l'ensemble des services testés sur les machines virtuelles précédemment : base, web, caches, balancement, haute disponibilité.
• Noter CHAQUE écart rencontré (adresses, interfaces, paquets, performances) : ces notes sont la matière du nouveau guide, le livrable clé de la semaine.

Partagez-vous les rôles : pendant que deux personnes installent, une documente et une prépare le test de charge. Une équipe, quatre métiers.

Mesurer, afficher, débrancher

• Test de charge BRUTAL contre la grappe : captures top et tableau (le matériel réel a ses propres chiffres, souvent surprenants).
• La démonstration officielle : WordPress affiché dans un navigateur, servi par le cluster. Nécessaire pour obtenir des points.
• Et le grand geste : pendant la charge, débrancher un Pi (un noeud redondé...). L'architecture tient. C'est votre travail des huit dernières semaines qui tient.

Livrables et la suite

• GitHub /laboratoire4/ : le nouveau guide de l'équipe (commits de chaque membre), fichiers de configuration, tableau rempli, captures. PDF unique pour l'équipe.
• Rangement du matériel : disques identifiés, câbles roulés, le prochain groupe hérite d'un chariot propre.
• Devoir : compléter le nouveau guide avant la semaine 10.

La semaine prochaine : la démonstration. Chaque équipe montre son cluster; chaque étudiant démontre ses laboratoires sur son poste. Le module 2 se clôt, et la petite entreprise est prête pour son grand oeuvre : le projet haute-disponibilité.