[LINUX] Construire un environnement distribué avec la série Raspberry PI (Partie 2: Analyse PiServer et conception de système alternatif)

introduction

  1. Création d'un environnement distribué avec la série Raspberry PI (Partie 1: Résumé de la disponibilité des clients sans disque par modèle)
  2. Création d'un environnement distribué avec la série Raspberry PI (Partie 2: Analyse PiServer et conception de système alternatif)
  3. Création d'un environnement distribué avec la série Raspberry PI (Partie 3: Installation et configuration de dnsmasq)
  4. Création d'un environnement distribué avec la série Raspberry PI (Partie 4: Création d'un serveur NFS et importation d'un système d'exploitation pour les clients)
  5. Création d'un environnement distribué avec la série Raspberry PI (Partie 5: Personnalisation du Raspberry PI OS pour les nœuds de cluster (1))
  6. Création d'un environnement distribué avec la série Raspberry PI (Partie 6: Personnalisation de Raspberry PI OS pour les nœuds de cluster (2))
  7. Création d'un environnement distribué avec la série Raspberry PI (7: réglage d'itinéraire tftp et test de démarrage pour chaque tarte à la râpe)

Cet article est la suite de la Partie 1. Raspberry PI Il s'agit de construire un système alternatif avec PiServer, qui est un logiciel qui est sûr d'entrer en contact avec de nombreuses personnes qui ont des essais et des erreurs pour devenir un client sans disque. Si vous rencontrez le problème que votre tarte aux râpes n'est pas reconnue par PiServer, veuillez consulter la Partie 1.

Présentation de PiServer

L'annonce officielle est ici (en anglais). Si vous utilisez un PC avec Raspberry PI Desktop installé, vous pouvez rendre Raspberry 3B ou version ultérieure sans disque.

Puisque la tarte aux râpes était à l'origine faite à des fins éducatives, les élèves ont utilisé un grand nombre de tartes à la râpe dans la salle de classe. Il semble que l'enseignant ait été créé dans un environnement où le même écran est visualisé sur un PC.

Alors touchons Raspberry PI Desktop

Vérifiez les fonctions et la méthode d'implémentation de PiServer

1. Découverte du client Raspeye
Recevez la diffusion DHCP de Raspeye et enregistrez l'adresse MAC comme cible de gestion. La fonction DHCP de dnsmasq accroche la demande reçue. Préparez une route tftp dédiée à l'adresse MAC enregistrée (symbolisez le répertoire de démarrage du système d'exploitation géré)
2. Importer l'image du système d'exploitation pour le client Réalisé avec le script
bash. J'ai copié le contenu du fichier image sur mon disque local et ajouté une entrée dans / etc / exports. En passant, j'ai supprimé les fichiers inutiles pour le client sans disque et réécrit les relations locales avec les mêmes valeurs que la machine exécutant Raspberry PI Desktop. C'est aussi une réécriture furtive de / etc / fstab, qui est censée monter le disque local
3. fonction serveur tftp Il est réalisé par
dnsmaq. Je suis en train de bricoler le fichier de configuration dnsmasq à partir de l'interface graphique
4. Serveur de cache DNS / fonction ddns Il est réalisé par
dnsmasq. Si vous avez déjà un autre serveur DNS, ou si vous n'avez pas besoin de cette fonctionnalité parce que vous voulez simplement pouvoir la gérer dans / etc / hosts, vous devez spécifier le numéro de port comme 0 dans le fichier /etc/dnsmasq.conf >
5. Fonction serveur DHCP Réalisé avec
dnsmasq. Si un autre serveur DHCP existe déjà, il fonctionne également en tant que proxy DHCP, renvoyant uniquement l'adresse du serveur tftp pour télécharger les fichiers nécessaires au démarrage vers le client.
6. Fonction serveur NFS
Utilisez le serveur NFS (ver3) intégré au noyau depuis le début. Fournit un système de fichiers racine pour les clients. Même les clients sans disque peuvent souhaiter stocker leurs données, ils fournissent donc également un dossier partagé inscriptible à monter pendant le processus de démarrage une fois que le système de fichiers racine a été monté.
7. Modifier le système d'exploitation client
Gérez quelle image du système d'exploitation est donnée à la tarte aux râpes enregistrée. Il suffit de réécrire la route tftp pour chaque adresse MAC avec un lien symbolique
8. Gestion des comptes utilisateurs sur Raspai
Je n'ai pas vérifié en détail car il n'y a aucun intérêt à l'utiliser, mais il semble qu'il soit réalisé par OpeLDAP
9. Modifiez l'image du système d'exploitation pour le client géré J'exécute juste chroot en utilisant la commande
qemu-arm-static. La glibc étant la version i386, la commande qemu-aarch64-static n'est pas installée, de sorte que la distribution de la version 64 bits ne peut pas être gérée.

Avez-vous vraiment besoin d'un environnement de bureau Raspberry PI?

Quand j'ai vérifié la source publiée dans GitHub piserver repository, j'ai trouvé la source C ++ de l'interface graphique de gestion et divers scripts bash. La partie GUI pouvait être compilée et exécutée sur la version x86_64 d'ArchLinux, il s'est donc avéré qu'il n'était pas nécessaire d'utiliser Raspberry PI Desktop. De plus, une fois que le script bash publié dans le référentiel PiServer a été porté, toutes les fonctions restantes peuvent être réalisées avec juste dnsmasq + OpenLDAP + qemu-user-static.

  • Je n'ai pas besoin d'une interface graphique qui réécrit simplement le fichier de configuration de dnsmasq. --PiServer est de la merde (décision finale) après tout.

Comment construire un système alternatif PiServer

L'autre jour, le Raspberry officiel a annoncé Make Raspberry PI OS 64bit, et gérer la distribution 64 bits. Si vous ne pouvez pas PiServer, vous devez abandonner. Pensons donc à une méthode pour construire un système alternatif.

Prérequis: comportement général du client sans disque (démarrage PXE IPv4)

Que fait le client + serveur avec le démarrage PXE (séquence)

(Référence: https://japan.zdnet.com/article/20089685/)

  1. Un client qui n'a pas d'adresse IP sur le disque lance une diffusion et essaie d'obtenir une adresse IP du serveur DHCP.
  2. Le serveur DHCP détermine si le demandeur est un client sans disque enregistré en fonction de l'adresse MAC du client, etc.
  3. S'il est déterminé qu'il ne s'agit pas d'un client sans disque, il sera terminé en donnant une adresse IP, etc. S'il est déterminé qu'il s'agit d'un client sans disque enregistré, le serveur DHCP donnera une adresse IP au client demandeur, puis tftp à visiter ensuite. Dites-moi l'adresse IP du serveur et le rôle du serveur DHCP est terminé.
  4. Un client ayant sa propre adresse IP accède au serveur tftp appris et télécharge le noyau et les fichiers associés nécessaires au démarrage. Lorsque tous les fichiers nécessaires au démarrage ont été téléchargés, le rôle du serveur tftp est terminé.
  5. Le fichier téléchargé depuis tftp doit toujours contenir l'emplacement du serveur NFS qui fournit le système de fichiers racine et le nom du répertoire partagé, de sorte que le client monte le répertoire partagé spécifié en tant que système de fichiers racine en lecture seule. Essayer.
  6. Le système de fichiers racine est monté et le démarrage réel du système d'exploitation démarre.

Serveurs d'infrastructure requis pour réaliser le démarrage PXE

Par conséquent, pour réaliser la procédure ci-dessus, il est nécessaire de préparer au moins l'environnement suivant, et un serveur avec ces trois fonctions est parfois appelé "serveur PXE".

  • Serveur DHCP
  • serveur tftp
  • Serveur de fichiers tel que NFS

À l'origine, les clients sans disque sont généralement utilisés pour des applications où de nombreux utilisateurs utilisent le même environnement, comme les terminaux étudiants dans les établissements d'enseignement et les terminaux d'entreprise de saisie de données.

  • Serveur DNS (enregistrement automatique du nom d'hôte du client)
  • Serveur d'authentification interne tel que LDAP / NIS
  • Passerelle / Pare-feu

Toutefois, étant donné que l'objectif final de cet article est de créer un environnement de traitement distribué personnel, le contenu lié aux trois serveurs suivants ne sera pas décrit. Soit dit en passant, DNS sera nécessaire si le nombre de clients dépasse 100, mais si le nombre de clients est inférieur à 10, la résolution de nom par le fichier / etc / hosts est suffisante et ce fichier peut être partagé sur le serveur NFS. Vous n'en avez pas besoin. Au fait, dans un environnement distribué que vous seul utilisez, vous n'avez pas besoin d'un serveur d'authentification, et vous n'en avez pas besoin car vous pouvez partager le fichier / etc / passwd.

Méthode de réalisation 1: Construisez tftp / DHCP / DNS collectivement avec dnsmasq, un logiciel spécialisé dans la construction de serveurs PXE.

Construire un serveur DHCP, tftp ou DNS avec des logiciels individuels tels que dhcpd, atftpd ou bind est fastidieux et prend du temps. Par conséquent, un logiciel appelé dnsmasq, qui est également utilisé dans PiServer, est introduit. À l'origine, ce logiciel a commencé son développement en tant que serveur de cache DNS, mais il n'est pas exagéré de dire qu'il s'agit d'un logiciel spécialisé dans la construction d'un serveur PXE car il a incorporé les fonctions du serveur tftp et du serveur DHCP avant que je le sache. Faisons le. Naturellement, j'utiliserai ce logiciel. Cependant, n'utilisez pas de DNS, qui est l'objectif initial.

Désormais, la machine x86_64 exécutant dnsmasq sera appelée "serveur PXE".

Réalisation 2: la fonction serveur NFS doit être séparée du serveur PXE.

Dans PiServer, toutes les fonctions ont été emballées afin de vendre "complet avec un PC", mais compte tenu de la sécurité, il est préférable de séparer la fonction serveur NFS dans une autre machine. En effet, si le serveur PXE fait également office de serveur NFS, les situations suivantes peuvent se produire.

  1. Lorsque je redémarre / arrête le serveur PXE, le système de fichiers racine du Raspai en cours d'exécution est perdu. Pour éviter cela, tous les Rasppies doivent être arrêtés avant de redémarrer le serveur PXE.
  2. Plus grave lorsqu'une panne de disque se produit sur le serveur PXE.

Si vous disposez déjà d'un serveur de fichiers prenant en charge NFS, ce sera un système plus robuste car il sera redondant avec RAID, GlusterFS, etc. Il n'y a aucun problème si les fichiers liés au démarrage distribués par tftp sont également montés NFS à partir du serveur PXE. Cependant, je pense qu'il est préférable d'utiliser une machine avec un accès rapide au disque.

Par la suite, une machine dotée de la fonction NFS sera appelée «serveur NFS».

[^ Raison]: Si vous avez un serveur de fichiers existant, il sera redondant avec RAID, GlusterFS, etc.

Réalisation 3: Importation du fichier image d'installation du système d'exploitation vers le serveur NFS

Vous pouvez le faire manuellement. Cependant, il peut être possible de l'automatiser en modifiant le script bash pour l'importation du système d'exploitation publié sur le GitHub de PiServer.

Réalisation 4: émulateur armhf / aarch64 requis pour mettre à jour le système d'exploitation client

Les clients sans disque montent le système de fichiers racine en lecture seule, vous ne pouvez donc pas mettre à jour le système d'exploitation du côté client. Vous devrez mettre à jour le système d'exploitation côté serveur PXE ou NFS. Cependant, l'environnement que vous essayez de créer cette fois doit être un ARM côté client et une machine x86_64 côté serveur. C'est là que vous avez besoin d'un émulateur.

Cette méthode est également implémentée dans PiServer, mais l'émulateur qemu (mode utilisateur statique), le support binfmt et chroot facilitent le contrôle du système d'exploitation distribué aux clients. Vous pouvez en savoir plus ici [http://blog.kmckk.com/archives/2342452.html).

Sur les systèmes Debian, il vous suffit d'installer le paquet qemu-user-static, et sur ArchLinux, vous devez le compiler vous-même avec AUR.

Réalisation 5: Gestion des adresses MAC du client

Si vous avez 10 tartes à la râpe ou moins, ce n'est pas un gros problème de les vérifier individuellement en utilisant la méthode décrite dans Mon article précédent.

Méthode de réalisation 6: DNS / fonction de gestion des utilisateurs

Puisqu'il s'agit d'un groupe de clients que je n'utilise que moi, je n'ai pas besoin de le gérer, je vais donc l'omettre.

  • Gestion des utilisateurs de / etc / passwd + / etc / shadow avec le partage NFS
  • La fonction DHCP de DNqmasq résout + / etc / hosts, qui alloue une adresse IP fixe à chaque tarte rasp, avec un partage NFS

Tout sera résolu en faisant.

Forme définitive

L'auteur décide de construire un tel environnement. Le serveur PXE, le serveur NFS et le contrôleur peuvent être combinés en une seule unité ou les sous-réseaux ne peuvent pas être séparés. RaspiCloudSystem.png

Alors c'est tout pour cette fois. La prochaine fois veut réellement installer et configurer dnsmasq sur la machine Linux x86_64.

Recommended Posts