Übermässige Redundanz?
Hallo Forum
Ich bin gerade dabei, mir zu Hause ein kleiner "Cluster" aufzubauen. Einige mögen jetzt den Kopf schütteln, aber es geht mir vor allem um den Erfahrungswert, nicht ob es "sinnvoll" ist, zu Hause einen Cluster aufzubauen (mit "nach dem Sinn fragen" sollte man bei Informatiker so oder so etwas vorsichtig sein :P)
Ich habe zwei HP ML110G5 am laufen.
Darauf soll in Zukunft ein Virtualisierungs-Cluster mittels "Proxmox VE" (KVM) und DRBD ("RAID1 über Netzwerk").
Die Server sind mehr oder weniger gleich ausgestattet. Jeder Server hat einen RAID-Controller (HP E200) drin, daran hängen:
1x 160GB (Primary normalerweise auf Host A)
1x 250GB (Primary normalerweise auf Host B)
1x 1TB (Primary normalerweise auf Host A)
1x 500GB (Primary normalerweise auf Host B)
Mit Verwendung von DRBD über eine "dedizierte" Netzwerkkarte (direkte Crossover-Verbindung) werden nun die Festplatten zwischen beiden Servern auf Block-Level-Ebene ständig synchron gehalten (also ein RAID1 übers Netzwerk).
Dadurch kann auch Live-Migration für die VMs benutzt werden, da beide Server zwar nicht auf die genau gleiche Storage, aber auf den gleichen Stand der Daten (jeweils lokal) zugreifen können.
Fällt nun eine Festplatte aus hat dies einen gravierenden Nachteil gegenüber einem RAID1 am RAID-Controller: Die VMs, die auf dem "fehlerhaften" Host liefen, werden natürlich unschön gestoppt.
Allerdings hat es auch einen schönen Vorteil: Wenn nicht die Festplatte, sondern z.B. der RAID-Controller oder das Mainboard des Server abschmiert, so wäre bei einem lokalen RAID1 dann "tote Hose".
So aber kann die VM einfach wieder auf dem anderen Host neu gestartet werden.
Das sicherste wäre natürlich ein lokales RAID1, dass übers Netzwerk noch gespiegelt wird, allerdings erscheint mir doppelte Redundanz etwas "oversized".
Um sich gegen einen "generellen" Hostausfall (egal ob Festplatte, CPU, RAM, ...) zu wappnen, könnte man die Redundanz natürlich auf einer höheren Ebene weiterführen:
Die meisten VMs werden redundant ausgelegt, beispielsweise Web, DB, Mail, Proxy, Router. Auf jedem Host lauft je eine VM davon.
Somit läuft beispielsweise die Webseite Ausfall-frei weiter. Z.B. der Fileserver (wohl eher schwierig, den redundant auszulegen) müsste bei einem Hostausfall manuell auf dem anderen Host wieder gestartet werden.
Allerdings braucht dies natürlich doppelt soviele Ressourcen (auch Festplatten-Platz), kann aber in einem Aktiv/Aktiv-Setup auch zusätzlich als Load-Balancing verwendet werden.
Keine konkrete Frage, aber habt ihr dazu irgendwelche Anregungen / Ideen?
Gruss
lousek
Ich bin gerade dabei, mir zu Hause ein kleiner "Cluster" aufzubauen. Einige mögen jetzt den Kopf schütteln, aber es geht mir vor allem um den Erfahrungswert, nicht ob es "sinnvoll" ist, zu Hause einen Cluster aufzubauen (mit "nach dem Sinn fragen" sollte man bei Informatiker so oder so etwas vorsichtig sein :P)
Ich habe zwei HP ML110G5 am laufen.
Darauf soll in Zukunft ein Virtualisierungs-Cluster mittels "Proxmox VE" (KVM) und DRBD ("RAID1 über Netzwerk").
Die Server sind mehr oder weniger gleich ausgestattet. Jeder Server hat einen RAID-Controller (HP E200) drin, daran hängen:
1x 160GB (Primary normalerweise auf Host A)
1x 250GB (Primary normalerweise auf Host B)
1x 1TB (Primary normalerweise auf Host A)
1x 500GB (Primary normalerweise auf Host B)
Mit Verwendung von DRBD über eine "dedizierte" Netzwerkkarte (direkte Crossover-Verbindung) werden nun die Festplatten zwischen beiden Servern auf Block-Level-Ebene ständig synchron gehalten (also ein RAID1 übers Netzwerk).
Dadurch kann auch Live-Migration für die VMs benutzt werden, da beide Server zwar nicht auf die genau gleiche Storage, aber auf den gleichen Stand der Daten (jeweils lokal) zugreifen können.
Fällt nun eine Festplatte aus hat dies einen gravierenden Nachteil gegenüber einem RAID1 am RAID-Controller: Die VMs, die auf dem "fehlerhaften" Host liefen, werden natürlich unschön gestoppt.
Allerdings hat es auch einen schönen Vorteil: Wenn nicht die Festplatte, sondern z.B. der RAID-Controller oder das Mainboard des Server abschmiert, so wäre bei einem lokalen RAID1 dann "tote Hose".
So aber kann die VM einfach wieder auf dem anderen Host neu gestartet werden.
Das sicherste wäre natürlich ein lokales RAID1, dass übers Netzwerk noch gespiegelt wird, allerdings erscheint mir doppelte Redundanz etwas "oversized".
Um sich gegen einen "generellen" Hostausfall (egal ob Festplatte, CPU, RAM, ...) zu wappnen, könnte man die Redundanz natürlich auf einer höheren Ebene weiterführen:
Die meisten VMs werden redundant ausgelegt, beispielsweise Web, DB, Mail, Proxy, Router. Auf jedem Host lauft je eine VM davon.
Somit läuft beispielsweise die Webseite Ausfall-frei weiter. Z.B. der Fileserver (wohl eher schwierig, den redundant auszulegen) müsste bei einem Hostausfall manuell auf dem anderen Host wieder gestartet werden.
Allerdings braucht dies natürlich doppelt soviele Ressourcen (auch Festplatten-Platz), kann aber in einem Aktiv/Aktiv-Setup auch zusätzlich als Load-Balancing verwendet werden.
Keine konkrete Frage, aber habt ihr dazu irgendwelche Anregungen / Ideen?
Gruss
lousek
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 180154
Url: https://administrator.de/forum/uebermaessige-redundanz-180154.html
Ausgedruckt am: 22.12.2024 um 14:12 Uhr
9 Kommentare
Neuester Kommentar
Hi lousek,
ich würde hier einfach einen Server als NFS Server bereit stellen, in Produktivsystemen kommst du damit natürlich nicht weit - da muss dann ne NetApp oder so her.
Ich selbst beschäftige mich auch recht viel mit Cluster,
und hab mir dafür auch ein "großes" Heimnetzwerk gebaut:
1x) CISCO Catalyst - 48Port Full Managed
1x) CISCO Small Business GigaBit Switch
1x) HP Proliant @ 3TB HDD
7x) MikroTik 750G
2x) Server selfmade
lg,
Stefan
ich würde hier einfach einen Server als NFS Server bereit stellen, in Produktivsystemen kommst du damit natürlich nicht weit - da muss dann ne NetApp oder so her.
Ich selbst beschäftige mich auch recht viel mit Cluster,
und hab mir dafür auch ein "großes" Heimnetzwerk gebaut:
1x) CISCO Catalyst - 48Port Full Managed
1x) CISCO Small Business GigaBit Switch
1x) HP Proliant @ 3TB HDD
7x) MikroTik 750G
2x) Server selfmade
lg,
Stefan
Hi lousek,
was möchtest du denn Primär Clustern?
Willst du das gesammte Versuchsnetzwerk komplett Redundant haben, oder z.B. "nur" die VM-s?
Für zweiteres würde dir ja meine vorgeschlagene Lösung reichen, damit kannst du dich auf den Cluster
konfiguration an sich konzentrieren und musst dir keine Gedanken um die Storage machen.
Im RZ würde hier klarerweise 2x Switches sowie 2x NetApp vorkommen.
lg
was möchtest du denn Primär Clustern?
Willst du das gesammte Versuchsnetzwerk komplett Redundant haben, oder z.B. "nur" die VM-s?
Für zweiteres würde dir ja meine vorgeschlagene Lösung reichen, damit kannst du dich auf den Cluster
konfiguration an sich konzentrieren und musst dir keine Gedanken um die Storage machen.
Im RZ würde hier klarerweise 2x Switches sowie 2x NetApp vorkommen.
lg
Nicht zwangsläufig, du kannst ein NFS Share als Datastore einbinden.
ProxMox kann lt. Wiki (http://pve.proxmox.com/wiki/Proxmox_VE_Cluster) auch Clustering, solltest du mal testen...
ProxMox kann lt. Wiki (http://pve.proxmox.com/wiki/Proxmox_VE_Cluster) auch Clustering, solltest du mal testen...
Ich würde mal sagen, das man hier keine genauen Grenzen ziehen kann - kommt im weiterem Sinne auf den Anwendungsfall an,
wenn bei einem Privatkunden die Website mal nen Tag nicht erreichbar ist soll das so sein,
aber bei ner größeren Firma würde ich schon mehr Geld in einen vernünftigen Cluster stecken ...
Für ein Versuchsnetzwerk würde ich persönlich zu zweiterem Ansatz tendieren und einen Vollen Cluster aufbauen,
d.h. Switches, Server, Storage, Uplink voll Redundant.
wenn bei einem Privatkunden die Website mal nen Tag nicht erreichbar ist soll das so sein,
aber bei ner größeren Firma würde ich schon mehr Geld in einen vernünftigen Cluster stecken ...
Für ein Versuchsnetzwerk würde ich persönlich zu zweiterem Ansatz tendieren und einen Vollen Cluster aufbauen,
d.h. Switches, Server, Storage, Uplink voll Redundant.