Also das 100MBit LAN was man auf den Boards findet läuft problemlos (VIA, nVidia), ansonsten halt für 5¤ ne Realtek rein und fertigPascal hat geschrieben:[...]Michael H.W. Weber hat geschrieben:..
Haupsache, die Mobos booten auch über LAN! Reicht da 10/100 MBit? Pascal hatte mal Bedenken angemeldet und sicher bin ich mir auch nicht.
Michael.
Bezüglich LAN ist da eher die Frage, ob's für die Boards mit Onboard-LAN bereits Linuxtreiber gibt.
Hardwarespenden
- Michael H.W. Weber
- Vereinsvorstand
- Beiträge: 22435
- Registriert: 07.01.2002 01:00
- Wohnort: Marpurk
- Kontaktdaten:
Natürlich läuft das problemlos - habe es ja selbst. Die Frage war, ob für einen CLUSTER ohne "node"-eigener Festplatte (z.B. unter MOSIX) GBit LAN her muß.Desti hat geschrieben:Also das 100MBit LAN was man auf den Boards findet läuft problemlos (VIA, nVidia),
Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.
http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B
http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B
Naja für ein bisschen booten und aller paar Sekunden mal ein Zwischenergebnis speichern reichen 100MBit (= theoretisch 12,5MB/s – vor ein paar Jahren Traumwerte einer jeden IDE Festplatte ) locker aus (vorausgesetzt, jede Node hat ihren eigenen DC-Client) sollte der Cluster am Ende jedoch als EIN Rechner funktionieren so sind imo 100MBit zu wenig - Frage ist hier ob das bei - auf DC optimierten - Clients wirklich sinnvoll ist.Michael H.W. Weber hat geschrieben: Die Frage war, ob für einen CLUSTER ohne "node"-eigener Festplatte (z.B. unter MOSIX) GBit LAN her muß.
-
- Task-Killer
- Beiträge: 777
- Registriert: 05.09.2001 01:00
- Wohnort: Porta Westfalica
- Kontaktdaten:
Vorausgesetzt - auf dem Cluster sollen verschiedene Projekte gleichzeitlig laufen - könnte ein Teil der Nodes ohne eigene Festplatten laufen (hier kommen dan 'festplattenschonende' Projekte zum Einsatz), der andere Teil ist mit eigenden FPs für entspr. intensive Projekte.
Momentan ist das Ganze aber nur eine Idee, am Anfang wird der Cluster nur aus zwei oder vier Nodes bestehen und da macht eine solche Aufteilung keinen Sinn.
Momentan ist das Ganze aber nur eine Idee, am Anfang wird der Cluster nur aus zwei oder vier Nodes bestehen und da macht eine solche Aufteilung keinen Sinn.
Irgendwie schießt ihr alle brutalst über das Ziel hinaus.
Der 'Cluster' muß folgendermaßen aussehen - nehmen wir mal 4 Nodes an:
1 Server-Node mit Festplatte, Graka, Tastatur usw.
3 Nodes mit Netzwerkkarte (10 MBit reichen völlig, aber es gibt eh nur noch min. 100 MBit) und sonst gar nichts.
Das Ding funktioniert so:
Erst muß der Server komplett gebootet werden. Dann werden die Nodes gebootet. Der Server stellt jedem Node seine eigene Boot-'Partition' zur Verfügung. Per Netz-Boot-Protokoll (weiß jetzt nicht, wie das heißt) bootet jeder vom Server Linux und seine Settings. Jeder Node rechnet seine WU. Jeder Node sieht sein Verzeichnis auf der Server-Festplatte wie wenn es seine eigene Festplatte wäre (NFS machts möglich). Jeder Node kann über den Server aufs Internet zugreifen, schickt seine WUs selber ab und holt sich selber neue. Der Server funktioniert genauso, wenn er nicht gerade servt. Die Nodes können per rsh überwacht werden.
Alle Phantastereien, daß eine WU auf allen Nodes gleichzeitig parallel berechnet wird, könnt ihr euch komplett abschminken, weil:
a) die meisten DC-Clients das gar nicht ermöglichen
b) das ein riesiger Installations und Wartungsaufwand wäre
c) überhaupt nicht sichergestellt wäre, daß alle CPUs immer voll ausgelastet sind - das würde davon abhängen, wie gut der Client programmiert ist.
Sorry für den vielleicht etwas harschen Ton, aber ich hab die Kirche wieder ins Dorf zurückstellen müssen.
Der 'Cluster' muß folgendermaßen aussehen - nehmen wir mal 4 Nodes an:
1 Server-Node mit Festplatte, Graka, Tastatur usw.
3 Nodes mit Netzwerkkarte (10 MBit reichen völlig, aber es gibt eh nur noch min. 100 MBit) und sonst gar nichts.
Das Ding funktioniert so:
Erst muß der Server komplett gebootet werden. Dann werden die Nodes gebootet. Der Server stellt jedem Node seine eigene Boot-'Partition' zur Verfügung. Per Netz-Boot-Protokoll (weiß jetzt nicht, wie das heißt) bootet jeder vom Server Linux und seine Settings. Jeder Node rechnet seine WU. Jeder Node sieht sein Verzeichnis auf der Server-Festplatte wie wenn es seine eigene Festplatte wäre (NFS machts möglich). Jeder Node kann über den Server aufs Internet zugreifen, schickt seine WUs selber ab und holt sich selber neue. Der Server funktioniert genauso, wenn er nicht gerade servt. Die Nodes können per rsh überwacht werden.
Alle Phantastereien, daß eine WU auf allen Nodes gleichzeitig parallel berechnet wird, könnt ihr euch komplett abschminken, weil:
a) die meisten DC-Clients das gar nicht ermöglichen
b) das ein riesiger Installations und Wartungsaufwand wäre
c) überhaupt nicht sichergestellt wäre, daß alle CPUs immer voll ausgelastet sind - das würde davon abhängen, wie gut der Client programmiert ist.
Sorry für den vielleicht etwas harschen Ton, aber ich hab die Kirche wieder ins Dorf zurückstellen müssen.
Genau das hatte ich ja vorgeschlagen. Von Pascal kam allerdings der berechtigte Einwand, dass ein Ausfall des Servers gleich den gesamten Cluster lahmlegt. Deshalb sollten wir darüber nachdenken, ob es nicht sinnvoller ist, jedem Node eben doch eine eigene Festplatte zu spendieren, statt das Dateisystem per NFS zu mounten.
Ach, und wie soll der Ausfall des Servers aussehen?LinuxFan hat geschrieben:Genau das hatte ich ja vorgeschlagen. Von Pascal kam allerdings der berechtigte Einwand, dass ein Ausfall des Servers gleich den gesamten Cluster lahmlegt. Deshalb sollten wir darüber nachdenken, ob es nicht sinnvoller ist, jedem Node eben doch eine eigene Festplatte zu spendieren, statt das Dateisystem per NFS zu mounten.
Wenn irgendein Bauteil (CPU, RAM, etc.) davon ausfällt, dann wirst Du es halt aus einem Node herausnehmen und in den Server einbauen müssen. Dann ist, bis die Ersatzteillieferung eintrifft, ein Node ausgefallen. Das kann man nie verhindern.
Und wenn die Server-Festplatte crasht? Vielleicht sollte der Server ein RAID 1 haben? Aber nein, Du solltest vom komplett eingerichteten Server ein Image auf CD brennen, damit die neue Platte ruck-zuck wieder eingerichtet ist. Die paar verlorenen, halb berechneten WUs im Falle eines Plattencrashs sind wirklich nicht tragisch.
Denn was verlieren wir, wenn der Server ausfällt? Ein paar Stunden, höchstens Tage, Rechenzeit. Und dafür sollen wir 3 Platten kaufen und den zusätzlichen Strom zahlen? Nein danke, so wertvoll ist die Rechenzeit dieses Clusters wirklich nicht - wenn man bedenkt, daß der Server im statistischen Mittel nicht mal alle 5 Jahre einen Plattencrash haben wird. Bei uns steht schließlich keine millionenschwere Produktion still, wenn der Computer ausfällt.
Bitte denkt etwas realitätsnaher und professioneller.
- Michael H.W. Weber
- Vereinsvorstand
- Beiträge: 22435
- Registriert: 07.01.2002 01:00
- Wohnort: Marpurk
- Kontaktdaten:
Also MOSIX einzusetzen - sofern es möglich ist - ist genau alles andere als unsinnig, sofern man z.B. Folding@home als Projekt wählt.
Für Folding@home macht es durchaus einen Unterschied, ob man eine gegebene WU von einem "node" in 3 Tagen durchrechnen läßt oder - unter MOSIX - in einem Clusterverbund bestehend aus 3 "nodes" innerhalb eines Tages. Der Grund ist einfach der, daß neue WUs auf den Ergebnissen der alten basieren. Je schneller die WUs zurückgeschickt werden, desto rascher schreitet auch das Projekt als Ganzes voran. Die Projektleiter von FAH betonen immer wieder, daß WUs so schnell wie möglich zurückgeliefert werden sollen.
Aus diesem Grund wäre ich UNBEDINGT dafür, den Cluster von vorn herein so zu planen, daß ein echter Clusterbetrieb (MOSIX, ClusterKNOPPIX) prinzipiell möglich ist. Ob wir es später dann wirklich nutzen, sei dahingestellt. Ich bin nur kein Freund vom Verbauen nützlicher Möglichkeiten...
Michael.
Für Folding@home macht es durchaus einen Unterschied, ob man eine gegebene WU von einem "node" in 3 Tagen durchrechnen läßt oder - unter MOSIX - in einem Clusterverbund bestehend aus 3 "nodes" innerhalb eines Tages. Der Grund ist einfach der, daß neue WUs auf den Ergebnissen der alten basieren. Je schneller die WUs zurückgeschickt werden, desto rascher schreitet auch das Projekt als Ganzes voran. Die Projektleiter von FAH betonen immer wieder, daß WUs so schnell wie möglich zurückgeliefert werden sollen.
Aus diesem Grund wäre ich UNBEDINGT dafür, den Cluster von vorn herein so zu planen, daß ein echter Clusterbetrieb (MOSIX, ClusterKNOPPIX) prinzipiell möglich ist. Ob wir es später dann wirklich nutzen, sei dahingestellt. Ich bin nur kein Freund vom Verbauen nützlicher Möglichkeiten...
Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.
http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B
http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B
Mal abgesehen davon, daß der FAH-Client einfach nicht multiprozessortauglich ist, kann das gar nicht so sein. Da die zur Zeit 227 Proteine untersuchen, könnten sie dann auch nur 227 Clients beschäftigen. Nein, an jedem Protein werden viele Versuche durchgeführt. Innerhalb jedes Versuchs mag ein Schritt auf dem vorherigen basieren. Wenn unsere 4 Nodes gleichzeitig bei deren Server nach WUs fragen, werden sie an 4 verschiedenen Versuchen arbeiten. Jeder dieser 4 Versuche schreitet dann so schnell voran wie auf einem Node möglich - also wesentlich schneller als auf dem durchschnittlichen FAH-Rechner (Rechenkraft-Durchschnitt: 1,3 GHz).Michael H.W. Weber hat geschrieben:[...]Für Folding@home macht es durchaus einen Unterschied, ob man eine gegebene WU von einem "node" in 3 Tagen durchrechnen läßt oder - unter MOSIX - in einem Clusterverbund bestehend aus 3 "nodes" innerhalb eines Tages. Der Grund ist einfach der, daß neue WUs auf den Ergebnissen der alten basieren. Je schneller die WUs zurückgeschickt werden, desto rascher schreitet auch das Projekt als Ganzes voran. Die Projektleiter von FAH betonen immer wieder, daß WUs so schnell wie möglich zurückgeliefert werden sollen.[...]
Die FAH-Betreiber wollen nur verhindern, daß sich jemand monatelang für eine WU Zeit läßt - das sieht man auch an den gegenwärtigen Deadlines.