Cluster für den Heimgebrauch

[CommodoreX64]

Hi zusammen,

zugeben, ein etwas ungewöhnliches / nerdiges Thema. Dennoch würde mich euere Anregungen zu dem Thema interessieren.

Seit x Jahren habe ich im Keller einen Hyper-V Server stehen auf dem je nach Bedarf, und was ich gerade am testen oder rumspielen bin, etwa Windows 20 VMs laufen. Über die Jahre hat sich natürlich einiges an der Hardware geändert usw. Vor einiger Zeit kam mir nun die Idee statt eines einfachen Hyper-V Hosts einen 2 Knoten-Cluster aufzubauen um meine VMs darauf laufen zu lassen. Zu größentechnischen Orientierung: Aktuell hat mein Server 32GB RAM und etwa 30TB Speicher. Wäre natürlich gut, wenn das neue System dann Luft nach oben hätte.

Hat jemand einen Home-Cluster im Keller stehen und kann man sein Erfahrungen teilen?
Was wären denn "vernünftige" (wenn man bei so einem Vorhaben überhaupt noch von Vernunft sprechen kann) Komponenten, die ich dazu verwenden könnte (und nicht jedes Budget sprengen oder Strom ohne Ende fressen)?
Ich würde mal davon ausgehen 2 kleine Server (wahrscheinlich Eigenbau) und irgendein Storage zu brauchen (oder eben einen 3ten Server der als Storage fungiert).

Ich hoffe die Idee ist nicht allzu schwachsinnig.

Danke & Grüße,
CommodoreX64

 

[p4n0]

Fuer daheim Cluster? Mit zentralem Storage? Stromsparend?
Forget it

 

[CommodoreX64]

Von stromsparend war nicht die Rede. Ich schrieb von "nicht Strom ohne Ende fressen".
Außerdem... ein 0815 NAS + zwei Intel NUCs sind IMHO z.B. was den Stromverbrauch anbelangt wahrscheinlich besser als meine bisherige Kiste.

 

[Luckysh0t]

Kann denn deine Hyper V Lizenz überhaupt dass was du möchtest ? (Bin nicht in der Hyper V Welt zu hause - evtl eine blöde Frage da alles inkl xD)

 

[CommodoreX64]

Ja, kann sie.

 

[konfetti]

Naja, Stromsparend heist ja nicht, das er nur 50W für alles verbraten will, sondern, das es sich im Rahmen hält, und wenn ich bedenke, wie der Unterschied zwischen den G5 und den G7/8/9 ist, dann merkt man das schon auch.

Aktuell habe ich zwar so keinen Cluster laufen, aber wenn man 2 Diskless Server annimmt, mit vlt. nur 1 NT und 1 CPU + weniger aber größere RAM-Riegel, sollte sich das ja noch etwas relativieren - mein ESXi mit Xeon 5650, 144GB RAM (9x 16GB Module) und 6 Disks liegt im Schnitt bei nicht mehr als 115W - eher weniger - das ist 24/7 vertretbar.

Wenn man zu Grunde legt, das ein RAM-Riegel ca. 5W braucht, er jetzt mit 32 auskommt, könnte man da wohl schon 35W sparen - gut, müsste ein 2ter und 3ter Server her, aber je nach Ausstattung kann man da ja noch was an Einsparung raus holen.

Wenn ich heut Abend dazu komm, kann ich ja mal den Diskless 360G7 entsprechend so konfigurieren und anwerfen, dann mess ich das mal ^^ - die sollten am Markt ja günstig zu beschaffen sein - dann braucht man nur 1 größeren für Storage.

bei 30TB - Netto oder Brutto? - Welche Verfügbarkeit und hast Du da schon an ein Backup gedacht?
benötigt der Storage für den Cluster auch wirklich so viel? - welche Bauform, wenn Du das weiter verwenden willst?

Gruß konfetti

 

[p4n0]

Die Compute Nodes sind doch gar nicht das Problem.
Schwierig wirds beim Storage, die Dinger sind sehr schnell sehr teuer.
Ist denn HA eine Anforderung oder dient das lediglich dem Basteltrieb?

 

[konfetti]

Ich hätte jetzt aus seiner obigen Anforderung rausgelesen, das er entweder was fertiges als NAS oder selbstbau Homeserver einsetzen möchte... - dafür würd ich aber erstmal abchecken, welche Größenordnung und welcher Speed wirklich genutzt werden - für 20 Windows VMs braucht man an sich ja keine 30TB Speicher... - selbst wenn mans mit 100GB Pro Windows VM und Thick Provisioning ausreitzt reichen 2TB - die gehn dann als SSD-Speicher auch recht schnell und "günstig" her - bei mehr wirds ggf. sportlich.

Ich würde z.B. den Storage für VMs von der normalen Datenablage trennen - auch wenns ein System ist.

 

[besterino]

Hab dazu ja mal vor einiger Zeit mit Hyper-V recht viel rumgespielt: [Sammelthread] Microsoft Hyper-V Stammtisch und insbesondere hier [Sammelthread] Microsoft Hyper-V Stammtisch

Mit Microsoft würde ich mir heute wohl nochmal Storage Spaces Direct (S2D) genauer anschauen - wenn ich das richtig in Erinnerung habe, kann man damit ja gerade Storage über mehrere 08/15 Nodes verteilen.

ABER: für Live Migration wie glaub auch für S2D benötigt man mehr als der freie Hyper-V mitbringt: Datacenter bzw. (zusätzlich) Active Directory, also (min.) einen Domaincontroller.

Zunächst lassen sich zwei Hyper-V Server auch kostenlos zu einem Cluster bringen, wenn man entweder auf live migration verzichtet oder die Domäne außerhalb der Windows-Welt (z.B. mit Samba) baut.

Bleibt die Frage: Storage.

Ein echt redundantes Storage zu bauen, ist m.E. nicht trivial. Dafür braucht's dann entweder 2 weitere Maschinen oder man fummelt da was auf den Blechen hin, auf denen auch die Hyper-V Hosts laufen. Da gibt's dann wieder unterschiedliche Möglichkeiten, unter Windows selbst mit z.B. S2D oder vielleicht auch was ganz Abgefahrenes mit einem Software-Raid1 über iSCSI-Shares wechselseitig freigegeben auf den beiden Nodes, oder, oder, oder... oder man kann z.B. auch Hyper-V nested auf ESXi laufen lassen und hat dann neben der "Hyper-V-VM" noch je eine Storage-VM, die man miteinander verheiratet...

Naja, sinnvoll ist vermutlich anders.

Kommt jetzt halt darauf an, was Du mit dem Cluster machen willst. Rein zum Rumspielen würde ich wohl erst einmal eine etwas potentere Maschine nehmen, darauf ESXi als Host, der darauf 2 Hyper-V Hosts als VM bereitstellt. Zusätzlich dann noch eine Storage VM z.B. mit Solarish (oder irgendwas anderes, das iSCSI-Shares bereitstellen kann). Da darf man aber von der Performance in den VMs vermutlich nicht zu viel erwarten... Wenn's etwas mehr sein darf und wirklich der Ausfall einer physischen Kiste abgefedert werden soll, würde ich vermutlich für den Einstieg 3 physische Maschinen nehmen, 2x Hyper-V Hosts und eine 3. Maschine (nur) für Storage zusätzlich zu den beiden Cluster-Nodes. Dazu noch eine gescheite Backup-Strategie und wenn die Storage-Kiste sich verabschiedet, hast Du halt in Sachen Dauerbetrieb Pech gehabt und Dein Cluster stirbt.

Mix von alldem ist auch denkbar: Zum Beispiel gedanklich eine Kiste wirklich nur als Backup vorsehen mit ESXi als Host, auf dem dann eine Storage-VM (falls das Hauptstorage abraucht) und eine Hyper-V-VM (falls der Haupt-Hyper-V abraucht) laufen, dann könnte theoretisch mindestens eine beliebige und im "best worst case" sogar zwei physische Maschinene (main Hyper-V und zugleich main storage) den Geist aufgeben und Du wärst noch "online"...

Selbst getestet habe ich diese Verästelungen & Optionen aber nicht mehr: Ich habe dann irgendwann beschlossen, dass ich privat keinen Cluster brauche (wobei das für manche Geschichten schon nett war).

Wie die anderen auch schon schrieben, neben der "Redundanz-Logik" stellt sich sehr schnell die Performance- und Preisfrage: 30TB voll redundant sind halt 60TB netto. Und es ist was anderes, ob da Filme vor sich hingammeln oder Hosts plus VMs mit all ihren Caches drauf rumtanzen. Wenn da allein 10 Windows-Auslagerungsdateien auf dem Storage liegen, willst Du keine HDDs dafür... und bei den SSDs muss man auch mal einen Blick auf die (Schreib)Last werfen, welche für den eigenen Einsatzzweck geeignet sind.

So, und dann gibt es auch das Netzwerk zu bedenken - ich wage mal zu zweifeln, dass Du mit einem "ein-gigabit-Netz" da viel Spaß haben wirst. Müsste man aber wohl auch einfach mal ausprobieren.

 

[-INU-]

Das Cluster als Jugendtraum des kleinen Nerds, aber über den Zustand Server kaufen weil billig ist es bei mir dann auch nie hinausgekommen.
Dafür habe ich aber noch 2 six Mode Pi Cluster zusammengetackert, sind stromsparend und können dank Aktivitätsanzeige in allen Regenbogenfarben blinken
War insofern auch ein Recht befriedigendes Projekt.

Und viel mehr als den Wunsch nach einem Cluster lese ich aus deinem Post auch nicht heraus. Kein Zweck oder Ziel, nicht mal ein Budget oder Ausgangssituation um sich einen Nutzen zurechtzubiegen.

 

[gea]

Ein Cluster, das sind ja zunächst einfach mehrere Servernodes die eine IT Dienstleistung hochverfügbar bereitstellen, sei es Storage, sei es ein Serverdienst wie SMB, eine Datenbank oder WWW. Man muss dann noch unterscheiden ob es primär um Hochverfügbarkeit geht oder auch um Lastverteilung z.B. bei Active/Active Systemen oder ob einfach ein zweites System bei technischen Problemen, oder was häufiger der Fall ist bei Wartungen (Updates, Patches, Upgrades) bereitsteht damit man in kurzer Zeit (z.B. max 30s) auf das Zweitsystem umschalten kann (Active/Passive).

Es dreht sich also immer um mindestens zwei Server, um redundanten Storage und um redundante Dienste. Mann kann jetzt mehrere Server nehmen, dazu eine Clustersoftware wie PaceMaker oder RSF-1 bei ZFS, dazu ein Clusterfilesystem oder Dualpath SAS. Mehrere Server in einem Gehäuse nennt sich dann Cluster in a Box. Alles richtig teuer und meist richtig complex.

Ich habe jetzt mein All in One Konzept das ich seit 10 Jahren für einen ESXi Server mit Storage VM propagiere zur Idee eines vCluster in a Box erweitert. Damit geht ein Cluster mit einem ESXi Server und virtualisierten nodes, also auch ideal für Lab Installationen, idealerweise mit dualpath SAS Platten aber auch mit Sata/Nvme und ESXi shared disks. Extrakosten, nahe null, am ehesten etwas mehr RAM bei minimaler Komplexität dank ZFS. Mit Solaris und ZFS kann man als Cluster Servicemanegement ZFS selber nutzen, man braucht also PaceMaker un Co nicht. Bleibt nur Failover Management und Maßnahmen um gleichzeitigen Zugriff zu vermeiden (Stonith)

Mein Howto
http://www.napp-it.org/doc/downloads/z-raid.pdf

 

[CommodoreX64]

Naja, Stromsparend heist ja nicht, das er nur 50W für alles verbraten will, sondern, das es sich im Rahmen hält, und wenn ich bedenke, wie der Unterschied zwischen den G5 und den G7/8/9 ist, dann merkt man das schon auch.

Danke fürs klarstellen genau so wars gemeint. Also soviel Strom wie nötig aber keine 500W CPU also übertriebenes Beispiel.

bei 30TB - Netto oder Brutto? - Welche Verfügbarkeit und hast Du da schon an ein Backup gedacht?
benötigt der Storage für den Cluster auch wirklich so viel? - welche Bauform, wenn Du das weiter verwenden willst?

Verfügbarkeit ist sekundär. Backup ist kein Thema. Ich zieh das Zeug, das mir backupwürdig ist, immer wieder auf ein Synology NAS, welches ich extra fürs Backup einschalte und das sonst ausgeschaltet und räumlich getrennt rumsteht.

Ist denn HA eine Anforderung oder dient das lediglich dem Basteltrieb?

Nein, HA ist keine Anforderung. Lediglich Bastelbetrieb + Homebetrieb.

Ich hätte jetzt aus seiner obigen Anforderung rausgelesen, das er entweder was fertiges als NAS oder selbstbau Homeserver einsetzen möchte... - dafür würd ich aber erstmal abchecken, welche Größenordnung und welcher Speed wirklich genutzt werden - für 20 Windows VMs braucht man an sich ja keine 30TB Speicher... - selbst wenn mans mit 100GB Pro Windows VM und Thick Provisioning ausreitzt reichen 2TB - die gehn dann als SSD-Speicher auch recht schnell und "günstig" her - bei mehr wirds ggf. sportlich.

Nein, die Windows Installationen in den VMs brauchen nicht viel Platz. Das sind vielleicht im Schnitt 30 GB.
Ich habe aber zwei Fileserver laufen die sich über DFSR synchronisieren und einen Datenstamm von etwa 5TB, also insgesamt 10TB belegen.

Mit Microsoft würde ich mir heute wohl nochmal Storage Spaces Direct (S2D) genauer anschauen - wenn ich das richtig in Erinnerung habe, kann man damit ja gerade Storage über mehrere 08/15 Nodes verteilen.

S2D ist schon ne nette Sache, weil es das Problem des dedizierten Storage löst, allerdings hat das auch ziemliche Hardwareanfordungen an die Disks (Cache Disk, ich glaube mindestens 6 (?) Disk, Enterprisehardware Disks und keine Consumer etc...)

ABER: für Live Migration wie glaub auch für S2D benötigt man mehr als der freie Hyper-V mitbringt: Datacenter bzw. (zusätzlich) Active Directory, also (min.) einen Domaincontroller.

Ich habe mich da im Ausgangspost vielleicht missverständlich ausgedrückt. Ich habe genug Datacenter Lizenzen und muss nicht den freien Hyper-V Server verwenden.

Ein echt redundantes Storage zu bauen, ist m.E. nicht trivial.

Das Storage muss nicht redundant sein. Wenn das über den Jordan geht muss ich halt mein Backup bemühen. Ist dann halt so. Wichtig ist eben, dass es als Clusterstorage verwendet werden kann.

Wie die anderen auch schon schrieben, neben der "Redundanz-Logik" stellt sich sehr schnell die Performance- und Preisfrage: 30TB voll redundant sind halt 60TB netto.

Wie gesagt, Redundanz brauche ich nicht, daher bleibts bei 30TB.

So, und dann gibt es auch das Netzwerk zu bedenken - ich wage mal zu zweifeln, dass Du mit einem "ein-gigabit-Netz" da viel Spaß haben wirst. Müsste man aber wohl auch einfach mal ausprobieren.

Ich hätte daran gedacht, das über Teaming zu Lösung. Dann hätte ich halt 2 oder 4 Gbit. Sicher nicht das nonplus ultra, aber wenn ich bei 4 Gbit netto etwa 350-400MB übers Netz geschaufelt bekomme pro Sekunde, müssen das meine Disks auch erstmal mitmachen.

Und viel mehr als den Wunsch nach einem Cluster lese ich aus deinem Post auch nicht heraus. Kein Zweck oder Ziel, nicht mal ein Budget oder Ausgangssituation um sich einen Nutzen zurechtzubiegen.

Hauptzweck ist Spielwiese und Datenablage.

Danke für eure Antworten.
Grüße, CommodoreX64

 

[besterino]

S2D sollte auch außerhalb der Specs funktionieren. Halt nicht so performant und ohne Support.

 

[CommodoreX64]

Storage Device Anbindung:
Für Storage Spaces Direct benötigen wir zwingend einen Hostbus Adapter (HBA)

Einfacher Pass-Through SAS HBA für SAS und SATA Devices
SCSI Enclousure Services (SES) für SAS und SATA Devices
Jedes Direct-Attached Storage Enclosure muss eine Unique ID präsentieren.

Bei den SSDs müssen Enterprise SSDs verwendet werden, die „Power-loss Protection“ unterstützen.

=> Extrateuer

Bei den Cache Laufwerken ist folgendes zu beachten: die SSDs oder NVMe’s sollten einen DWPD (Drive Write per Day) Wert von mindesten 3 haben oder mit 4TB pro Tag beschrieben (TBW) werden können...

Minimunanzahl Laufwerke pro Knoten (ohne die Betriebssystem Festplatten):

2 Cache Laufwerke und
4 Kapazität Laufwerke

Quelle: Teil 2 – Grundlegende Anforderungen für Storage Spaces Direct | Hyper-V Server Blog


Ansich schon ne geile Sache...aber eben alles andere als billig zu haben.

 

[wenzilinho]

Naja, bei der Quelle bauen die das aber scheinbar für eine produktive Umgebung mit 32TB pro Node. Deshalb der HBA, powerloss protection und die hohe TBW des Caches.

 

[Toupman]

Powerloss Protection ist zwingend erforderlich, sonst nimmt S2D die SSDs nicht.

Es gibt zudem eine grobe Kalkulationsmethode was die Größe des Caches angeht.

Die muss ich aber erstmal noch raussuchen.

Wir haben ein S2D Cluster für unser zukünftiges ERP System laufen und die Performance ist schon Hammer.

Unser ganz ganz grober Vergleich damals war die Zeit in einer leeren VM ein Windows Server 2016 zu installieren. Vom letzten Klick bis zum Anmeldebildschirm.

In unserem S2D Cluster ist das aktuell unter 3 Minuten. Auf unseren schnellen Lefthand Nodes waren wir immer über 4 Minutern und auf den langsameren bei ca. 6.

 

[VirtuGuy]

Mit Microsoft würde ich mir heute wohl nochmal Storage Spaces Direct (S2D) genauer anschauen - wenn ich das richtig in Erinnerung habe, kann man damit ja gerade Storage über mehrere 08/15 Nodes verteilen.

Im Grunde bringt es neben Redundanz v.a. Performance. Ein Active/Active Storage ist halt Sexy, speziell wenn man mal mehr als 4 Hosts hat. Dazu braucht man aber auch entsprechende Bandbreite, 10Gbit sind bei einem Nvme/Nvdimm Setup viel zu wenig - das treibt heute eher verstärkt 100Gbit in die Storage Netze (und so nebenbei treibt es auch die Kosten).

ABER: für Live Migration wie glaub auch für S2D benötigt man mehr als der freie Hyper-V mitbringt: Datacenter bzw. (zusätzlich) Active Directory, also (min.) einen Domaincontroller.

Zunächst lassen sich zwei Hyper-V Server auch kostenlos zu einem Cluster bringen, wenn man entweder auf live migration verzichtet oder die Domäne außerhalb der Windows-Welt (z.B. mit Samba) baut

Live Migration geht auch ohne Shared Storage und Cluster, Replikation reicht im Grunde schon aus. Es dauert halt ein paar Sekunden länger. Es braucht auch kein AD, die beiden Knoten müssen sich nur "vertrauen".

S2D stellt im Grunde nur Storage bereit, Live-Migration ist davon nur bedingt abhängig. Es geht halt schneller.

Bleibt die Frage: Storage.

Ein echt redundantes Storage zu bauen, ist m.E. nicht trivial. Dafür braucht's dann entweder 2 weitere Maschinen oder man fummelt da was auf den Blechen hin, auf denen auch die Hyper-V Hosts laufen. Da gibt's dann wieder unterschiedliche Möglichkeiten, unter Windows selbst mit z.B. S2D oder vielleicht auch was ganz Abgefahrenes mit einem Software-Raid1 über iSCSI-Shares wechselseitig freigegeben auf den beiden Nodes, oder, oder, oder... oder man kann z.B. auch Hyper-V nested auf ESXi laufen lassen und hat dann neben der "Hyper-V-VM" noch je eine Storage-VM, die man miteinander verheiratet...

Eigentlich ist es recht einfach. Selbst in der Standard Version kann man per Storage Replica ein redundantes Setup aufbauen. Großartig viel Aufwand macht es nicht, die Frage ist ob nicht eine simple Hyper-V Replikation ebenso ausreichen würde.

 

[besterino]

Es braucht auch kein AD, die beiden Knoten müssen sich nur "vertrauen".

@VirtuGuy: Oh, hat sich da etwas geändert? Mein letzter Stand war irgendwie, dass beide Hosts Mitglied in Windows-Domänen sein müssen (und solche muss man eben irgendwie hinstellen). Vielleicht hab' ich das aber auch von vornherein falsch verstanden.

 

[VirtuGuy]

Über CredSSP geht es auch ohne AD, ich würde es aber nur für Lab/Testumgebungen nutzen. Ein DC ist mit Powershell mit ein paar Zeilen Code angelegt und fertig eingerichtet, selbst am freien Hyper-v. Von daher würde ich keine Zeit für Bastellösungen verschwenden.