Hallo, ich wollte vor längerer Zeit ebenso ein Projekt in starten. Leider kam ich nicht dazu da ich keine richtige gebrauchsfähige Anleitung dazu gefunden habe und bin hier auf das gesperrte Thema gestoßen. Hat hier jemand Ahnung wie es geht und vor allem es selber ausprobiert hat und berichten kann? Wunschvorstellung: 2 PCs mit 20 Kernen sollen mir einen Cluster mit 40 Kernen zur Verfügung stellen zwecks höherer Performance.
https://www.spektrum.de/magazin/der-selbst-gebastelte-supercomputer/828514 https://rantahar.github.io/introduction-to-mpi/ https://de.wikipedia.org/wiki/Message_Passing_Interface Es gab auch mal einen Artikel zum Rechnen mit MPI und mehreren Computern in einem c't-Heft - weiß jetzt aber nicht mehr genau, in welchem.
Esmu P. schrieb: > 2 PCs mit 20 Kernen kann man wohl kaum als besonders alt bezeichnen. Nimm einfach ein passendes Board mit mehr als einem CPU-Sockel. Und benutze dann die dazu passendes CPUs. Klassische Cluster aus Alt-PCs waren 486er und Pentiums. Steckt in so einem Cluster ein etwas besserer Rechner nebst CPU, übernimmt der ohnehin dann fast die gesamte Rechenlast. Fazit: Es lohnt nicht.
Du musst Dich erstmal fragen, was Du willst: Verbesserte Verfuegbarkeit des Systems oder (banal) mehr Rechenleistung. Mehr Rechenleistung ist geschenkt (obwohl anspruchsvoll) mit MPI. Beispiel waere z.B. ein Beowulff-Cluster. Betruebssystem waere z.B. MOSIX (der gewuenschte Effekt waere ein Single-System-Image so dass man nicht so viel Systemverwaltung machen muss). Ein white-Paper waere z.B. https://mosix.cs.huji.ac.il/pub/MOSIX_wp.pdf Die andere Anwendung waere ein HA-Cluster (High-Available-Cluster): Die Idee ist dann halt, dass wenn eine CPU ausfaellt, soll die Maschine (der Cluster) weiter verfuegbar sein (OpenVMS kann das off the Shelf, nach Einwurf von sehr sehr vielen Muenzen). Punkte zum Suchen waere distributed Lock-Manager, distributed System-Disk und Fail-Over. Als Intro vielleicht https://en.wikipedia.org/wiki/VMScluster Finale Stufe waere ein Tandem-Cluster: Jede Maschine macht auf OP-Code-Niveau und vergleicht die Ergebnisse (jedes bessere Flight-Management-System z.B. Eurofighter macht das) und macht wirft eine Warnung, wenn die Ergebnisse nicht gleich sind. Du brauchst natuerlich mindestens drei Rechner damit Du entscheiden kannst, wer falsch ist oder wer nicht.
Esmu P. schrieb: > Wunschvorstellung: 2 PCs mit 20 Kernen sollen mir einen Cluster mit 40 > Kernen zur Verfügung stellen zwecks höherer Performance. Was spricht gegen 1 Rechner mit 64 oder 128 Kernen?
:
Bearbeitet durch User
> Was spricht gegen 1 Rechner mit 64 oder 128 Kernen? Dafür spricht: * https://de.wikipedia.org/wiki/Von-Neumann-Architektur#Von-Neumann-Flaschenhals Früher Cluster für Linux Lullatsche verwendeten beowulf: * https://www.linux-magazin.de/ausgaben/2002/05/verkehrsplanung/
:
Bearbeitet durch User
Alt-PCs sind schon aus Sicht des Stromverbrauch keine wirklich gute Idee. Wesentlich sinnvoller ist es, sich einen kleinen ProxMox-Server aufzusetzen, und darauf erstmal einen kleinen Cluster aus VMs zum üben zu bauen. Für erste Erfahrungen bietet sich z.B. Kubernetes an. Das skaliert dann später auch problemlos über mehrere Maschinen. Sinnvoll ist sowas u.A. z.B. für die Heimautomatisierung. U.A. hier gibts sehr gute Tutorials zu dem Thema: https://www.youtube.com/playlist?list=PLXHMZDvOn5sVXjb88kYXSI7UMx4rhQwOj
:
Bearbeitet durch User
Harry L. schrieb: > Sinnvoll ist sowas u.A. z.B. für die Heimautomatisierung. Na klar. Ein Cluster aus 20 Rechnern für die Rollo-Steuerung. Gehts noch?
Angehängte Dateien:
-
LED-Kette.JPG
200 KB
Mehr beowulf: * https://www.blasbenito.com/post/beowulf-cluster/ * https://www.reddit.com/r/HPC/comments/1hzp9i8/putting_together_my_first_beowulf_cluster_and/?tl=de Hier im Forum findet man sicher viele Tipps zum Bau der im Anhang gezeigten LED-Kette.
Nemopuk schrieb: > Harry L. schrieb: >> Sinnvoll ist sowas u.A. z.B. für die Heimautomatisierung. > > Na klar. Ein Cluster aus 20 Rechnern für die Rollo-Steuerung. Gehts > noch? Ne, aber ein 2. Rechner mit autom. Failover macht durchaus Sinn! Das ist dann der kleinst mögliche Cluster.
:
Bearbeitet durch User
> Ne, aber ein 2. Rechner mit autom. Failover macht durchaus Sinn!
failover or fail lover - that is the question
Harry L. schrieb: > Ne, aber ein 2. Rechner mit autom. Failover macht durchaus Sinn! > Das ist dann der kleinst mögliche Cluster. Ein Failover mit 2 Rechner ist logisch nicht möglich. Dazu brauchst du mindestens 3 Rechner. Bedenke: Rechner 1 und Rechner 2 sind aktiv. Nun fällt Rechner 1 aus - woher weiß nun Rechner 2 ob Rechner 1 nicht aktiv ist oder ob nicht er selbst nicht mehr aktiv ist, oder ebenso Rechner 1 ob Rechner 2 nicht mehr erreichbar ist oder er selbst um die Resourcen aus- bzw. um-zulagern. D.h. du brauchst einen dritten Rechner der entscheidet ob er nun Rechner 1 nicht mehr sieht oder Rechner 2. Sprich, ein klassisches Failover funktioniert nur mit drei Teilnehmern - damit immer ein n>n-1 ist. Oder 2 Rechner + 1 Beobachter - wobei da die Gefahr besteht das der Beobachter ausfällt und nicht mehr entscheiden kann.
Rene K. schrieb: > Harry L. schrieb: >> Ne, aber ein 2. Rechner mit autom. Failover macht durchaus Sinn! >> Das ist dann der kleinst mögliche Cluster. > > Ein Failover mit 2 Rechner ist logisch nicht möglich. Dazu brauchst du > mindestens 3 Rechner. > > Bedenke: Rechner 1 und Rechner 2 sind aktiv. Nun fällt Rechner 1 aus - > woher weiß nun Rechner 2 ob Rechner 1 nicht aktiv ist oder ob nicht er > selbst nicht mehr aktiv ist, oder ebenso Rechner 1 ob Rechner 2 nicht > mehr erreichbar ist oder er selbst um die Resourcen aus- bzw. > um-zulagern. > > D.h. du brauchst einen dritten Rechner der entscheidet ob er nun Rechner > 1 nicht mehr sieht oder Rechner 2. Sprich, ein klassisches Failover > funktioniert nur mit drei Teilnehmern - damit immer ein n>n-1 ist. Oder > 2 Rechner + 1 Beobachter - wobei da die Gefahr besteht das der > Beobachter ausfällt und nicht mehr entscheiden kann. Stimmt so für einen ProxMox-Cluster, aber bei einem Kubernetes-Cluster, der in VMs auf einem oder mehreren ProxMox-Servern läuft, stellt sich das etwas anders dar. Da brauchst du eine ungradzahlige Anzahl Worker-Nodes (als VM) und auf jedem Proxmox einen Kubernetes-Master.(auch eine VM) Wenn jetzt ein ProxMox kompl. aufällt, werden alle laufenden Pods autom. auf den verbleibenden lebendigen Server migriert.
Harry L. schrieb: > Wesentlich sinnvoller ist es, sich einen kleinen ProxMox-Server > aufzusetzen, und darauf erstmal einen kleinen Cluster aus VMs zum üben > zu bauen. > > Für erste Erfahrungen bietet sich z.B. Kubernetes an. Ehrlich gesagt, würde ich für erste Erfahrungen eher Docker Swarm empfehlen, dazu einen Traefik für den Ingress und GlusterFS als verteiltes, redundantes Dateisystem. Kubernetes ist zwar mächtig, aber deswegen auch sehr komplex -- das würde ich eher für Cluster ab so etwa 100 bis 200 Nodes empfehlen, dabei kann es seine Stärken ausspielen, aber für kleinere Cluster erzeugt das viel administrativen Aufwand ohne einen echten Nutzen zu liefern. > Das skaliert dann später auch problemlos über mehrere Maschinen. Das tut ein Docker Swarm auch. > Sinnvoll ist sowas u.A. z.B. für die Heimautomatisierung. Naja, für SEHR große Häuser mit SEHR, SEHR vielen Sensoren und Aktoren... :-)
Rene K. schrieb: > Ein Failover mit 2 Rechner ist logisch nicht möglich. Dazu brauchst du > mindestens 3 Rechner. Das gilt für moderne Architekturen, die einen Konsens-Algorithmus wie Paxos oder Raft benutzen, und die daher auf eine Mehrheitsentscheidung angewiesen sind. Früher ging HA aber auch über gemeinsam gemountete Disks, sogenannte "Quorum Device" -- das hat auch sehr zuverlässig funktioniert, denn am Ende ging es ja nur darum, Splitbrains bei Ausfall der Connectivity zwischen den Nodes zu verhindern.
Harry L. schrieb: > Stimmt so für einen ProxMox-Cluster, aber bei einem Kubernetes-Cluster, > der in VMs auf einem oder mehreren ProxMox-Servern läuft, stellt sich > das etwas anders dar. Hm, Setups mit einem Container Orchestrator habe ich jetzt schon einige Male gesehen, aber nie verstanden. Wenn man ein paar Windows-Container benötigt oder IaaS anbietet, ok, da kann ich das noch nachvollziehen, wegen besserer Resource Utilization und des Geschäftsmodells. Aber sonst?
Rene K. schrieb: > Harry L. schrieb: >> Ne, aber ein 2. Rechner mit autom. Failover macht durchaus Sinn! >> Das ist dann der kleinst mögliche Cluster. > > Ein Failover mit 2 Rechner ist logisch nicht möglich. Dazu brauchst du > mindestens 3 Rechner. ??? Klar geht ausfallsicherheit durch redundanz aus dem Standby: https://de.wikipedia.org/wiki/Failover > Bedenke: Rechner 1 und Rechner 2 sind aktiv. Nun fällt Rechner 1 aus - > woher weiß nun Rechner 2 ob Rechner 1 nicht aktiv ist oder ob nicht er > selbst nicht mehr aktiv ist, oder ebenso Rechner 1 ob Rechner 2 nicht > mehr erreichbar ist oder er selbst um die Resourcen aus- bzw. > um-zulagern. > > D.h. du brauchst einen dritten Rechner der entscheidet ob er nun Rechner > 1 nicht mehr sieht oder Rechner 2. Mumpitz, die beiden Rechner fragen sich halt gegenseitig ab, kommt von dem einem Rechner keine Antwort, nimmt der Frager an, das der Befragte ein Problem hat. Also wird der Verstummte abgetrennt und still gelegt. Hier braucht es lediglich eine Prioritisierung, die verhindert, das die Rechner sich gegenseitig abschalten. Kann man bspw. über timeslots und time-synchronisierung (die man eh braucht) implementieren, Rechner A fragt in den ungeraden Sekunden, Rechner B in den geradzahligen. (dann hat man aber bei den Schaltsekunden Pech).
Naja, es ist nicht ganz klar, was Esmu mit "Performance" meint. Für mehrere VMs bzw. Linuxe und Unixe beispielsweise auf einem NB braucht es eigentlich nicht viel. Wenn es um schneller rechnen geht, sollen auch zwei gute Grafikkarten schon recht nützlich sein sein. Ein T. schrieb: >> Für erste Erfahrungen bietet sich z.B. Kubernetes an. > > Ehrlich gesagt, würde ich für erste Erfahrungen eher Docker Swarm > empfehlen, dazu einen Traefik für den Ingress und GlusterFS als > verteiltes, redundantes Dateisystem. Kubernetes ist zwar mächtig, aber > deswegen auch sehr komplex -- das würde ich eher für Cluster ab so etwa > 100 bis 200 Nodes empfehlen, dabei kann es seine Stärken ausspielen, > aber für kleinere Cluster erzeugt das viel administrativen Aufwand ohne > einen echten Nutzen zu liefern. es ist irgendwie auch ein wenig buzzwordisch in dieser Gegend, da müsste man wohl erstmal eine Menge lesen, um einigermaßen durchzusteigen.
> Naja, es ist nicht ganz klar, was Esmu mit "Performance" meint. Für > mehrere VMs bzw. Linuxe und Unixe beispielsweise auf einem NB braucht es > eigentlich nicht viel. Falls es hier uberhaupt um Performance und nicht um Zeitvertreib mit technik geht: " Hallo, ich wollte vor längerer Zeit ebenso ein Projekt in starten. ... 2 PCs mit 20 Kernen sollen mir einen Cluster mit 40 Kernen ..." Die Optionen, wie sich diese PC's verbinden lassen (Nullmodem, Ethernet, WLAN, ...) wird vom TO garnicht betrachtet, er schwafelt nur von "gebrauchsfähiger Anleitung" extra für ihn (und seinen "Niveau"). > Wenn es um schneller rechnen geht, sollen auch zwei gute Grafikkarten > schon recht nützlich sein sein. Ja, kommt aber auf die "Rechnung" an. Gehts es dagegen um Analyse von Terabyte von Daten auf einer einzelnen HD, dürfte der Grafikbeschleuniger als Coprozessor nur für noch mehr collision im Flaschenhals sorgen. Aber soll der TO mal bauen, Erfahrung macht klug.
Bradward B. schrieb: > Mumpitz, die beiden Rechner fragen sich halt gegenseitig ab, kommt von > dem einem Rechner keine Antwort, nimmt der Frager an, das der Befragte > ein Problem hat. Das "split brain" Szenario ist kein Mumpitz und die dritte (Dummy-)Node zur Entscheidung ist eine klassische Lösung dafür. https://en.wikipedia.org/wiki/Split-brain_(computing) In diesem Kontext begegnet man auch dem sehr bildhaften Akronym STONITH = „Shoot The Other Node In The Head“. https://en.wikipedia.org/wiki/Fencing_(computing)#STONITH Es hängt sehr davon ab, ob es um einen reinen Rechencluster geht, in dem der lokale Speicher einer Node keine relevanten Daten enthält, oder ob das Risiko besteht, dass jeweilig genutzte Speicher auseinander laufen und mindestens Datenverlust entsteht, ggf auch Inkonsistenzen.
:
Bearbeitet durch User
Bradward B. schrieb: > Mumpitz, die beiden Rechner fragen sich halt gegenseitig ab, kommt von > dem einem Rechner keine Antwort, nimmt der Frager an, das der Befragte > ein Problem hat Richtig, also das die beiden sich abfragen. Aber woher weiß dann die Node 1 ob der Fehler nicht bei sich selbst liegt oder bei Node 2. Und wenn die andere Node 2 ebenso Node 1 nicht mehr sieht und dann denkt das diese Defekt ist? Und wenn dann beide versuchen sich gegenseitig abzutrennen bricht das pure Chaos aus! Das Split-Brain Prinzip ist dir bekannt, richtig? Mumpitz ist das mit absoluter Sicherheit nicht.
Cartman E. schrieb: > Esmu P. schrieb: >> 2 PCs mit 20 Kernen > > kann man wohl kaum als besonders alt bezeichnen. Esmu hat keine PCs mit 20 Kernen, und kann auch keine Cluster bilden. Es will nur mal wieder einen völlig sinnlosen Trollbeitrag ins Forum werfen. Don't feed the trolls. Oliver
:
Bearbeitet durch User
In diesem Zusammenhang, also bei HA-Szenarien, ist auch zu bedenken, dass klassische Blech-Lösungen bei Servern heute eher zum alten Eisen gehören. Entsprechendes Knowhow ist dementsprechend nicht sehr zukunftsträchtig. Statt etliche HA-Paare für die verschiedenen Services aufzubauen, möglicherweise auch noch mit 3 verschiedenen Betriebssystemen je nach Anwendung, und 5 verschiedenen Verfahren, ist es deutlich einfacher, die HA-Funktionalität in eine wahrscheinlich ohnehin vorhandene Virtualisierungslösung zu verlagern.
:
Bearbeitet durch User
Ein T. schrieb: > Früher ging HA aber auch über gemeinsam gemountete > Disks, sogenannte "Quorum Device" Dieses Storage Device in SAN oder LAN ist effektiv eine weitere Node. Die klassische dritte Node in Form eines PC oder Einfachst-Servers entstammt Systemkonzepten, deren Storage nur mit lokalen Disks der Server arbeitet, nicht in LAN/SAN liegt.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Ein T. schrieb: >> Früher ging HA aber auch über gemeinsam gemountete >> Disks, sogenannte "Quorum Device" > > Ist auch heute noch so. Dieses Storage Device in SAN oder LAN ist > effektiv eine weitere Node. Die klassische dritte Node in Form eines PC > oder Einfachst-Servers entstammt Systemkonzepten, deren Speicher nur mit > lokalen Disks der Server arbeitet, nicht im SAN liegt. Aber Du moechtest aber die Devices local gemounted haben, wg. z.b. Record-Locks. Und da wird es mit Betriebssystemen und Filesystems schon duenn: Ich weiss von OpenVMS (mit dem MSCP-Driver) und IBM (Z-System, aber da ist alles so oder so anders). Wie sieht es bei MS und linux aus?
Thomas W. schrieb: > wg. z.b. Record-Locks. Die gibts auch im SAN, ob FC oder iSCSI. > Wie sieht es bei MS und linux aus? Da bin ich nicht unbedingt auf neuestem Stand, denn als aktuelle HA-Lösungen für Server sind wir seit langem auf VMware. HA-Blech über Microsoft-Server, AIX HACMP, Linux, ... ist Schnee von (vor)gestern. Nur Storage-Systeme haben so etwas noch. VMware erledigt diese Frage über shared Disks in LAN/SAN. Und reicht einem ein Server-Restart im Fehlerfall nicht aus, kann man in VMware etwas tun, was in Hardware extrem aufwändig ist: ein permanent vom ersten gespiegelter zweiter Server auf einem anderen Host, der im Fehlerfall übernimmt.
:
Bearbeitet durch User
Apropos... warum nimmt mein Win11 Rechner nur 16 von 64GB installiertem und erkanntem Arbeitsspeicher? Egal wieviel Apps ich laufen lasse, es werden nur 16GB verwendet, wie wenn ein "Zutritt verboten" Schild im Arbeitsspeicher eingebaut wäre.
Christian M. schrieb: > Apropos... warum nimmt mein Win11 Rechner nur 16 von 64GB installiertem > und erkanntem Arbeitsspeicher? Völlig andere Angelegenheit, die nicht in diesen Thread passt.
Rbx schrieb: > es ist irgendwie auch ein wenig buzzwordisch in dieser Gegend, da müsste > man wohl erstmal eine Menge lesen, um einigermaßen durchzusteigen. Clustering ist ganz unabhängig vom Clustertyp nunmal eine grundsätzlich sehr komplexe und darüber hinaus auch sehr flexible Veranstaltung. Da reicht die Lektüre eines Wikipedia-Artikels leider nicht aus.
Rene K. schrieb: > Richtig, also das die beiden sich abfragen. Aber woher weiß dann die > Node 1 ob der Fehler nicht bei sich selbst liegt oder bei Node 2. Das größte Risiko für Splitbrains ist ein Ausfall der Kommunikation zwischen den Clusternodes. Dagegen helfen auch redundante Interconnects nicht immer.
(prx) A. K. schrieb: > Dieses Storage Device in SAN oder LAN ist effektiv eine weitere Node. Es muß aber nicht zwangsläufig eine Netzwerklösung sein, in meiner Zeit bei Sun haben wir dazu meistens Sun StorEDGEs wie die D1000 verwendet, verbunden über Differential SCSI.
Thomas W. schrieb: > Aber Du moechtest aber die Devices local gemounted haben, wg. z.b. > Record-Locks. Und da wird es mit Betriebssystemen und Filesystems schon > duenn: Ich weiss von OpenVMS (mit dem MSCP-Driver) und IBM (Z-System, > aber da ist alles so oder so anders). > > Wie sieht es bei MS und linux aus? Da gibt es Dateisysteme wie Ceph, GlusterFS und AndrewFS, und als klassische einfache Lösung das Distributed Replicated Block Device (DRBD), das ähnlich wie PostgreSQL mit einem Master zum Schreiben und automatischer Replikation arbeitet. Locking wird in verteilten Umgebungen gerne mit Serveranwendungen wie etcd realisiert, zum Beispiel Kubernetes macht das so.
Ein T. schrieb: > Es muß aber nicht zwangsläufig eine Netzwerklösung sein, in meiner Zeit > bei Sun haben wir dazu meistens Sun StorEDGEs wie die D1000 verwendet, > verbunden über Differential SCSI. Opa erzählt vom Krieg. :)
Harry L. schrieb: > Alt-PCs sind schon aus Sicht des Stromverbrauch keine wirklich > gute > Idee. --> ausser man hat eine PV auf dem Dach und muß den "eigenverbrauch" noch oben bringen.
Nemopuk schrieb: > Harry L. schrieb: >> Sinnvoll ist sowas u.A. z.B. für die Heimautomatisierung. > > Na klar. Ein Cluster aus 20 Rechnern für die Rollo-Steuerung. Gehts > noch? Wieso? Das hat noch keiner gemacht!
(prx) A. K. schrieb: > Ein T. schrieb: >> Es muß aber nicht zwangsläufig eine Netzwerklösung sein, in meiner Zeit >> bei Sun haben wir dazu meistens Sun StorEDGEs wie die D1000 verwendet, >> verbunden über Differential SCSI. > > Opa erzählt vom Krieg. :) Vom Dreißigjährigen! ;)
Man nehme einen AMD Ryzen mit 256 GB Speicher 2-3 Graka und schon kann's losgehen. Budget: AMD Ryzen ca. 900,- Eur, Board auch ca. 800,- Eur, Speicher ca. 400,- Eur, GraKa ca. 1400,- Eut.
Thomas S. schrieb: > Man nehme einen AMD Ryzen mit 256 GB Speicher 2-3 Graka und schon kann's > losgehen. Budget: AMD Ryzen ca. 900,- Eur, Board auch ca. 800,- Eur, > Speicher ca. 400,- Eur, GraKa ca. 1400,- Eut. Leider hat das irgendwie so gar nichts mit einem Cluster zu tun, nach dem unser TO gefragt hatte... oder habe ich etwas verpaßt?
Mit etwas Phantasie kann man einen Ryzen mit mindestens 2 Core-Dies als eng gekoppelten Cluster interpretieren. 😁
Thomas S. schrieb: > Man nehme einen AMD Ryzen mit 256 GB Speicher 2-3 Graka und schon kann's > losgehen. Budget: AMD Ryzen ca. 900,- Eur, Board auch ca. 800,- Eur, > Speicher ca. 400,- Eur, GraKa ca. 1400,- Eut. Wenn AMD Server, dann schon einen Epyc und keinen Ryzen. Einen gebrauchten aus der 7er Reihe, einen 7601 für umme 100€ mit 32 Kernen und 64 Threads. Ein Sockel SP3 Board für 400€, dazu dann 256GB ECC DDR für 270€... Graka brauchst du nur wenn du auch wirklich Berechnungen drauf machst, LLM ist - so glaube ich - absolut nichts für ESMU, der scheitert ja schon an Windows. Da hat man was potentes zum spielen, vor allem: Serverhardware und kein Ryzen Consumer Zeugs.
Rene K. schrieb: > Wenn AMD Server, dann schon einen Epyc und keinen Ryzen. https://geizhals.de/?cat=cpuamdam4&xf=12099_Server%7E820_AM5&sort=p#productlist > Da hat man was potentes zum spielen, vor allem: Serverhardware und kein > Ryzen Consumer Zeugs. Was kann das besser?
Esmu P. schrieb: > Wunschvorstellung: 2 PCs mit 20 Kernen sollen mir einen Cluster mit 40 > Kernen zur Verfügung stellen zwecks höherer Performance. Sicherlich können wir bessere Ratschläge geben, wenn Du uns verrätst, was Du genau vor hast, und was für Daten Du wie verarbeiten möchtest.
G. K. schrieb: > Rene K. schrieb: >> Wenn AMD Server, dann schon einen Epyc und keinen Ryzen. >> >> Da hat man was potentes zum spielen, vor allem: Serverhardware und kein >> Ryzen Consumer Zeugs. > > Was kann das besser? Würdet Ihr Euch bitte ein Zim^W^Weinen eigenen Thread nehmen? Danke.
>> Da hat man was potentes zum spielen, vor allem: Serverhardware und kein >> Ryzen Consumer Zeugs. > Was kann das besser? Mehr Speicher, mehr Memory Channels. Wobei Threadripper reicht auch, aber auch da brauchts Memory Channels um die Kerne auszulasten.
>> Mumpitz, die beiden Rechner fragen sich halt gegenseitig ab, kommt von >> dem einem Rechner keine Antwort, nimmt der Frager an, das der Befragte >> ein Problem hat > > Richtig, also das die beiden sich abfragen. Aber woher weiß dann die > Node 1 ob der Fehler nicht bei sich selbst liegt oder bei Node 2. Health monitoring, built-in self-test, keep alive messages, ... > Und > wenn die andere Node 2 ebenso Node 1 nicht mehr sieht und dann denkt das > diese Defekt ist? Und wenn dann beide versuchen sich gegenseitig > abzutrennen bricht das pure Chaos aus! Deshalb der Verweis auf die time-slot prioritisierung. > Das Split-Brain Prinzip ist dir bekannt, richtig? Mumpitz ist das mit > absoluter Sicherheit nicht. "Split-brain" ist kein Fachtermini sondern ein buzzword, das muss man nicht kennen. Für ne Ausfallsicherung durch redundanz braucht es minimum zwei Maschinen, nicht drei. Das "Triple modular redundancy" prinzip wird nicht in der Netzwerkabsicherung verwendet, sondern in anderen Bereichen wo mal unerwartet bits kippen können. https://www.intel.com/content/www/us/en/docs/programmable/683128/21-3/triple-modular-redundancy.html Und jeder weitere Maschine erhöht den Aufwand der Absicherung - auch die neue dritte Maschine kann sich unspezifiziert verhalten. Deshalb KISS-Prinzip, lieber weniger Komplexität statt mehr. Das Spaceshuttle hat fünf redundante Bordcomputer und ist dann wegen einem simplen Dichtungsring explodiert. Weil sich der Maschinenbauingenieur von einem "Kommandotrupp" Informatikern und Projektmanagern hat einschüchtern lassen. * https://www.spiegel.de/politik/fehler-im-system-a-e4cb9ccc-0002-0001-0000-000013517925 * https://www.bernd-leitenberger.de/shuttle-bordcomputer.shtml
:
Bearbeitet durch User
Bradward B. schrieb: > "Split-brain" ist kein Fachtermini sondern ein buzzword, "Split Brain" ist bereits seit Jahrzehnten ein Fachterminus im Clustering und beschreibt einen Zustand, in dem der Cluster in mehrere Teile zerfällt. Wenn Du diesen Fachterminus nicht kennst, dann beweist das nur, daß Du weder Ahnung von, noch Erfahrung mit dem Thema hast, über das hier diskutiert wird. Schnell etwas ǵooglen wird Dir dabei auch nicht helfen, denn das Thema ist so komplex und vielfältig, daß jede seriöse Einarbeitung sehr (zeit)aufwändig ist.
Ein T. schrieb: > Bradward B. schrieb: >> "Split-brain" ist kein Fachtermini sondern ein buzzword, > > "Split Brain" ist bereits seit Jahrzehnten ein Fachterminus im > Clustering und beschreibt einen Zustand, in dem der Cluster in mehrere > Teile zerfällt Nicht ganz: DEC hatte es "cluster partitioning" genannt. Im wesentlichen dann, wenn die geographisch getrennten Maschinen ein Leitungsproblem hatten (so Groessenordnung zwischen zwei Bundesstaaten, mehr konnten die Leitungen nicht so richtig) und dann entschieden werden musste, welcher Teil ueberleben soll. Da kommt dann das Quorum ins Spiel: Vereinfacht ausgedrueckt, der Groessere gewinnt. Eine einzelne Maschine alleine hiess "embryonic cluster" :-) Der TO wollte so oder so keinen HA-Cluster, sondern nur einen computing Cluster und ist jetzt komplett erstaunt ueber MPI.
Thomas W. schrieb: > Ein T. schrieb: >> Bradward B. schrieb: >>> "Split-brain" ist kein Fachtermini sondern ein buzzword, >> >> "Split Brain" ist bereits seit Jahrzehnten ein Fachterminus im >> Clustering und beschreibt einen Zustand, in dem der Cluster in mehrere >> Teile zerfällt > > Nicht ganz: Aber ja doch und gar. "Split Brain" ist ein Fachausdruck und kein "Buzzword", wie es mein ahnungsloser Vorposter behauptet hat. :-) > DEC hatte es "cluster partitioning" genannt. Das steht meiner Aussage, daß "Split Brain" seit Jahrzehnten ein Fachausdruck ist, in keiner Weise entgegen. Daß DEC und andere dafür ihre eigenen Termini hatten, ist unbenommen -- ein "Buzzword" ist "Split Brain" trotzdem nicht -- und auch die alten DEC-Leute wissen, was damit gemeint ist. Edit: Satz vervollständigt.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.