LUGS - Vorträge: Clustering mit MOSIX vom 18.8.2000
LUGS Über die LUGS Statuten und Protokolle Sektionen Terminliste IRC Mailinglisten Kontaktadressen Mitglied werden Internes Mitgliederliste LINUX Was ist Linux?    Screenshots Distributionen    kmLinux Firmen Ressourcen LIB Dokumentation Events Projekte Vorträge Allgemeines ChangeLog Sprache Galerie	Am 18.8.2000 hat Marcel Baur einen Vortrag über Clustering mit MOSIX gehalten. Etienne Favey hat die Zusammenfassung geschrieben. Allgemeines Mosix läuft via UDP auf IPv4. Mehere Computer mit Linux bilden dabei einen Cluster durch Anwenden eines Kernel Patchs. Nach dem Anwenden des Patchs: Kernel kompilieren und rebooten. Dann kann der Computer beim Cluster angemeldet werden. Der Cluster kann Prozesse hin und her schieben. (Prozessmigration) Jeder Node im Cluster kriegt eine Nummer. Cluster Layout ist nötig. Durch die Datei: /etc/mosix.map. In diesem File sind Rechnernamen oder IP mit einer Node ID drinn: 1 node01 1 2 node02 1 3 node03 1 4 node04 1 Falls IP aufsteigend und aufeinanderfolgend sind, kann man auch folgende Zeile haben: 1 10.0.0.1 99 d.h. diese IP und die nächsten 99 sind im Cluster. Falls ein Node nicht antwortet, macht nichts, UDP-Paket geht ins leere. Sehr fehlertolerant. "Gateway Cluster" auch über Router möglich. Maschinen müssen binärkompatibel (Architektur) sein, aber die Libs, Distribution, etc. ist egal, können auch verschieden sein. Unix Process States Prozesslaufbahn: fork -> created -> ready to run -> etc. Wichtig ist die Trennung Usermode und Kernelmode! Mosix setzt auf Systemcall Schnittstellen auf. Jedesmal, wenn Prozess Kernel aufruft, Schnittstelle zu Kernel benutzt wird, greift MOSIX ein. Abschätzung, die der Kernel machen muss: soll man diesen Prozess migrieren? Entscheidungshilfen: Speicherverbrauch, Systemcalls an lokale Devices gebunden, ...? (Siehe /proc/mosix) Jeder Prozess hat eine Homenode. Dort ist Prozess im 'ps', und nur dort, auch wenn er auf anderem Node ausgeführt wird. Dort muss er abgeschossen werden. Pendant zu Programm top ist mtop für Cluster. Dies greift auf /proc/mosix zurück. Speziell /proc/mosix/nodes/<nodenummer>/{cpus,load,rmem,mem} Anhand dieser Infos wird entschieden, wohin der Prozess ausgelagert wird. Information decay einstellbar. infodaemon Infos up to date halten migdaemon Prozesse migrieren Migration Teile eines Prozesses wird unterschieden in Unix: User mode und Kernel Mode Mosix: Migratable und Deputy Deputy: wird nie migriert, system calls Migratable: text, user stack, datensegment, code segment Es gibt einen gefährlichen Zustand falls ein Node zu swappen beginnt. Dann akzeptiert er keine Migration von anderen Jobs mehr. Es kann den Cluster verlangsamen, wenn viele andere Node auf diesem Swappenden Prozesse haben. man kann auch manuell migrieren mit dem Befehl: migrate So kann man auch ausgelagerten Prozess zurückholen. Speziell: migrate home # zurückholen migrate balance # neu entscheiden Netzverkehr: bei 10Mbps ziemlich starke Belastung, bei 100Mbps nicht spürbar. Weitere Befehle: /sbin/setpe -w # Node in Cluster integrieren /sbin/setpe -off # Node aus Cluster nehmen mosctl - policy für mosix mosctl block # Gast Prozesse unterbinden mosctl noblock # Gast Prozesse erlauben mosctl stay # autom. Migration von eigenen Prozessen unterbinden mosctl nostay # autom. Migration von eigenen Prozessen erlauben Man kann die Kernel-Datei /proc/mosix/nodes/node_id/lock mit 0 oder 1 beschreiben, ob diese PID auslagerbar ist. Cluster-Typen, die aus obigen Möglichkeiten folgen: Single pool: alle gleiche Nodes, jeder Node migriert und empfängt andere Prozesse Server Cluster: ausgewählte Nodes als Cluster zusammengebunden. Man muss dort einloggen, um es nutzen zu können. Half-Duplex Pool: Workstation kann jobs an Server abgeben, aber nicht umgekehrt. Adaptive Pool: Server during work hours (half duplex) Workstations during off-hours (single pool) Installation http://www.mosix.cs.huji.ac.il/ http://www.mosix.org/ Vorsicht, es gibt verschiedene Versionen: In der Tabelle nachgucken, welche Linux Kernel Version man hat, entsprechende Mosix Version runterladen. tgz auspacken, mosix.install script starten Tunen /sbin/tune erzeugt dscosts.h, welches nach /usr/src/linux/mosix/dscosts.h muss. MFS Mosix File System (Feature, nicht Bedingung, um Mosix zu nutzen)) Aehnlich wie NFS, mit folgenden Features: mount -t mfs none /mfs Man kann via /mfs/1/ auf das root Filesystem von diesem Node 1 mit allen Rechten zugreifen! So kann man jedes File überall im Cluster sichtbar machen. Stabilität, Schlussbemerkungen Ist stabil, wenn Netzwerk stabil ist. Falls man eine problematische Netzwerkkarte hat, kann dies den ganzen Cluster nahezu zum stehen bringen. Mosix merkt, ob der Prozess viel IO macht und es sich nicht lohnt zum auslagern.