english version

  Beschreibung
  Screenshots
  •   Version 0.1
  •   Version 0.3
  •   Version 0.5
  •   Version 0.7
  •   Version 0.8
  •   Version 0.9
  •   Version 1.0
  •   MOSIXLOAD
  •   MOSIXMEM
  •   MOSIXHISTORY
  •   main-window


  •   Download
      bekannte Fehler
      FAQ
      HowTo
  • Install
  • main-window
  • configuration-win
  • migrator-win
  • remote-procs
  • execution-win
  • MOSIXVIEW-client
  • MOSIXCOLLECTOR
  • MOSIXLOAD
  • MOSIXMEM
  • MOSIXHISTORY
      Mailingliste
      Mirrors
      Danke

       HowTo
       MOSIX/diskless-clients

       HowTo
       MOSIX/MOSIXVIEW
       mit SSH

      openMosix HOWTO

      www.openmosix.org

      SourceForge Logo

      thanks to freshmeat.net
  • MOSIXVIEW
    Clustermanagment

    MOSIXVIEW Clustermanagment
    HOWTO MOSIX-Cluster mit diskless-nodes

    Als erstes muß ein DHCP-Server aufgesetzt werden, der die DHCP-Request für eine IP-Adresse eines Diskless-Clients beantwortet (ich werde diesen Rechner im folgenden "master" nennen). Dieser DHCP-Server exportiert zusätzlich die ganzen Client-Filesysteme der Cluster-Clients (die ich im folgenden "slaves" nenne), sodass sie sich das ganze FS (Filesystem),sobald sie eine IP-Adresse erhalten haben, beim booten "greifen" können.
    Den Server ansonsten "normal" mit MOSIX-Kernel konfigurieren. Im Kernel muß NFS-server-Support enabled sein!
    Es gibt zwei Arten von NFS (vielleich noch ein paar mehr):
      kernel-nfs
    or
      nfs-daemon
    Es spielt keine Rolle welches NFS benutzt wird aber meine Erfahrung zeigten mir: für "ältere" Kernels (z.B. 2.2.18) kernel-nfs und für neuere eher daemon-nfs benutzen.
    NFS in den "neueren" Kernels arbeitet manchmal nicht so wie erwartet.

    Wenn der master mit dem neuen MOSIX-Kernel läuft, erstellt man ein Filesystem für einen slave. Hier die einzelnen Schritte, um es zu erstellen.

    Man kalkuliert mindesten 300-500 MB für jeden slave ein und erstellt ein Extra-Verzeichnis für das ganze Cluster-Filesystem. Dieses Verzeichnis unbedingt nach /tftpboot verlinken (symbolic link). (Das /tftpboot-Verzeichnis oder der symbolische Link ist erforderlich, da die slaves beim booten das root-Verzeichnis Names /tftpboot/ip-adresse-des-slaves vom NFS-Server mounten. Man kann dies ändern, allerdings muß man dazu die Kernel-Sourcen editieren.)
    Dann wird ein Verzeichnis im Cluster-FS erstellt, dessen Name der IP-Adresse des slaves entspricht z.B.
      mkdir /tftpboot/192.168.45.45

    Abhängig vom Platten-Platz kopiert man nun das komplette Dateisystem des masters in das Verzeichnis für den ersten slave.
    Hat man nicht so viel Platten-Path kopiert man nur:

    /bin
    /usr/bin
    /usr/sbin
    /etc
    /var

    Man kann es später so konfigurieren, dass der Rest des Dateisystems per NFS gemounted wird.
    Es sollten jedoch die leeren Verzeichnisse für die Mount-Points erstellt werden.

    Die Filesystem-Struktur in /tftpboot/192.168.45.45/ sollte gleich der des masters sein.
    Nun muß man die folgenden Dateien editieren:

    /tftpboot/192.168.45.45/etc/HOSTNAME //insert the hostname of the slave
    /tftpboot/192.168.45.45/etc/hosts //insert the hostname+ip of the slave

    Abhängig von der Linux-Distribution die man benutzt konfiguriert man die IP-Konfiguration des slaves in:

    /tftpboot/192.168.45.45/etc/rc.config

    /tftpboot/192.168.45.45/etc/sysconfig/network

    /tftpboot/192.168.45.45/etc/sysconfig/network-scripts/ifcfg-eth0

    Die gesamte Netzwerk-Konfiguration des slaves wird entsprechend angepasst:

    Nun editiert man die Datei

    /tftpboot/192.168.45.45/etc/fstab //das NFS-Filesystem des slaves
    entsprechend zur
    /etc/exports //Das FS das der master für den slave freigibt

    des masters. Beispiel für eine slave fstab:

    master:/tftpboot/192.168.88.222 / nfs hard,intr,rw 0 1
    none /proc nfs defaults 0 0
    master:/root /root nfs soft,intr,rw 0 2
    master:/opt /opt nfs soft,intr,ro 0 2
    master:/usr/local /usr/local nfs soft,intr,ro 0 2
    master:/data/ /data nfs soft,intr,rw 0 2
    master:/usr/X11R6 /usr/X11R6 nfs soft,intr,ro 0 2
    master:/usr/share /usr/share nfs soft,intr,ro 0 2
    master:/usr/lib /usr/lib nfs soft,intr,ro 0 2
    master:/usr/include /usr/include nfs soft,intr,ro 0 2
    master:/cdrom /cdrom nfs soft,intr,ro 0 2
    master:/var/log /var/log nfs soft,intr,rw 0 2

    Beispiel für eine master exports:

    /tftpboot/192.168.45.45    *(rw,no_all_squash,no_root_squash)
    /usr/local    *(rw,no_all_squash,no_root_squash)
    /root    *(rw,no_all_squash,no_root_squash)
    /opt    *(ro)
    /data    *(rw,no_all_squash,no_root_squash)
    /usr/X11R6 *(ro)
    /usr/share    *(ro)
    /usr/lib    *(ro)
    /usr/include    *(ro)
    /var/log    *(rw,no_all_squash,no_root_squash)
    /usr/src    *(rw,no_all_squash,no_root_squash)

    Mounted man /var/log (rw) vom master (NFS-server) hat man einen Zentralen Log-File!
    (dies funktioniert gut. Nur ein "tail -f /var/log/messages" auf dem master und man hat die Übersicht was gerade los ist auf dem Cluster)

    Das Cluster-Dateisystem für den ersten slave ist jetzt fertig.
    Der slave-kernel wird nun konfiguriert und erstellt. Verwendet man dieselbe Hardware kann man die Kernel-Konfiguration des Master wiederverwerten. Man muß nur die folgenden Optionen anpassen:

    CONFIG_IP_PNP_DHCP=y
    and
    CONFIG_ROOT_NFS=y

    Man sollte so wenig Module wie möglich konfigurieren (vielleich gar keine), da es ein bischen tricky ist. Sie werden später sowieso vom Cluster-Filesystem des masters gemountet.

    Ein /dev/nfsroot-Device wird benötigt. Es ist nötig, um dem slave-kernel mitzuteilen von NFS zu booten. (dies ist sehr gut in einigen Beowulf-HOWTO's beschrieben)

       mknod /dev/nfsroot b 0 255
       rdev bzImage /dev/nfsroot

    "bzImage" ist hier der Diskless-Slave-Kernel den man in /usr/src/linux-version/arch/i386/boot nach erfolgreichem kompilieren findet.

    Jetzt ändert man das root-Device des Kernels

       rdev -o 498 -R bzImage 0

    und kopiert in auf eine Diskette.

       dd if=bzImage of=/dev/fd0

    Fast fertig! Ein DHCP-Server wird nun auf dem master aufgestzt. Die MAC-Adresse (Hardware-Adresse) der Netzwerkkarte des slaves wird benötigt.
    Der einfachste Weg ist, den slave einfach schon mal mit der erstellten Boot-Diskette zu booten (Dies wird zwar in jedem Fall fehlschlagen aber der slave teilt beim booten seine MAC-Adresse mit). Wenn der Kernel passend konfiguriert ist, sollte der slave von der Diskette booten, seine Netzwerkkarte erkennen und einen DHCP- bzw. ARP-Request senden. In diesem Moment wird die MAC-Adresse auf dem Bildschirm ausgegeben. Sie sieht zum Beispiel so aus: 68:00:10:37:09:83.

    Dann die Werte wie im folgenden Beispiel in der /etc/dhcp.conf eintragen:

    option subnet-mask 255.255.255.0;
    default-lease-time 6000;
    max-lease-time 72000;
    subnet 192.168.45.0 netmask 255.255.255.0 {
        range 192.168.45.253 192.168.45.254;
        option broadcast-address 192.168.45.255;
        option routers 192.168.45.1;
    }
    host firstslave
    {
        hardware ethernet 68:00:10:37:09:83;
        fixed-address firstslave;
        server-name "master";
    }


    Jetzt kann man den DHCP- und den NFS-Server mithilfe deren init-Skripts starten

       /etc/init.d/nfsserver start

      /etc/init.d/dhcp start

    You got it!! Das Cluster ist fast fertig!

    Nachdem man den ersten slave über die Diskette gebootet hat, sollte jetzt alles klappen. Der slave sollte sein root-Filesystem (und die restlichen Mounts) per NFS bekommen, sobald er eine IP-Adresse vom DHCP-Server zugeteilt bekommen hat (kurz nachdem er seine Netzwerkkarte erkannt hat).

    Alle Module, die man für slaves konfiguriert sollten auch auf dem master erstellt werden, da /lib von ihm exportiert. Das FS aus dem die slaves ihre Modules lesen wird per NFS gemounted. Also benutzen alle dieselben Module (wenn überhaupt Module konfiguriert worden sind).

    Es ist einfach upzudaten oder zusätzliche Applikationen zu installieren, wenn man so viel wie möglich vom master mounted (d.h. nicht in /tftpboot/192.168.45.45 kopiert sondern per NFS readonly direkt vom master mounted). Auf der anderen Seite hat man nicht so viele read/write Hits auf NFS-Verzeichnisse wenn jeder slave sein komplett eigenes Dateisystem hat.

    Man kann jetzt noch einen .rhosts-Datei in /root (für den User root) auf jedem Knoten anlegen. Sie sollte ähnlich dem folgenden Beispiel aussehen und erlaubt dann "rsh" ohne Passwort.

    node1 root
    node2 root
    node3 root
    ....

    Um Remote-Login für den User root zuzulassen jetzt noch folgende Zeilen in der /etc/inetd.conf editieren.

    shell stream tcp nowait root /bin/mosrun mosrun -l -z /usr/sbin/tcpd in.rshd -L
    login stream tcp nowait root /bin/mosrun mosrun -l -z /usr/sbin/tcpd in.rlogind

    Oder wenn man eine Linux-Distribution mit xinetd benutzt:

    service shell {
    socket_type = stream
    protocol = tcp
    wait = no
    user = root
    server = /usr/sbin/in.rshd
    server_args = -L
    }
    service login
    {
    socket_type = stream
    protocol = tcp
    wait = no
    user = root
    server = /usr/sbin/in.rlogind
    server_args = -n
    }

    Jetzt noch inetd restarten damit, er seine neue Konfiguration einliest ("/etc/init.d/inetd restart" oder "/etc/init.d/xinetd restart"). Es gibt meist noch einen Schalter im Konfigurations-Utility der benutzten Linux Version, wo man die Sicherheits-Einstellungen für das System vornehmen kann. Hier muß man auch "remote root login" enablen.
    RSH sollte man keinesfalls in einer unsicheren Netzwerkumgebung benutzen!!!
    SSH ist die sichere Alternative für RSH! MOSIXVIEW kann man mit RSH oder SSH benutzen.

    SSH für Remote-Login ohne Passwort zu konfigurieren, ist ein bisschen "Tricky". Das "HOWTO use MOSIX/MOSIXVIEW mit SSH?" auf dieser Webseite sollte hier weiterhelfen.

    Will man Dateien auf irgeneinen slave kopieren, hat man nun zwei Möglichkeiten. Man kann "rcp" oder "scp" für direktes Kopieren über das Netzwerk benutzen oder mit "cp" Dateien direkt auf dem master in das Cluster-Filesystem eines slaves kopieren. Die folgenen zwei Kommandos sind equivalent:

       rcp /etc/hosts 192.168.45.45./etc

       cp /etc/hosts /tftpboot/192.168.45.45/etc/


    howto erstellt von M. Rechenburg
    Ich habe etwas vergessen? Bestimmt. Mail was noch fehlt.