Hi, Ich möchte ein HA-Cluster mit 2 Nodes aufbauen. 3 Dienste sollen hochverfügbar sein, jeweils Webanwendungen mit einer Datenbank, später eventl. auch mehr. Ich will mit KVM für jeden Dienst eine VM bauen. Bleibt ein Node stehen, sollen auf dem anderen Node die VM's starten. Damit habe ich 1-2 Minuten Downtime, damit kann ich leben. Ich überlege, ob ich den Speicherplatz für die VM's als DRBD oder als Fibrechannel SAN zur Verfügung stellen soll. Der Speicherplatz wird den VM's als nackte, unformatierte Partition zur Verfügung gestellt, das soll schneller sein als eine Imagedatei. DRBD hat für mich den Vorteil, daß es billiger ist ( ca. 6000,-- € weniger ). Ein SAN hat den Vorteil, daß ich damit auch noch anderen Servern Speicherplatz zur Verfügung stellen kann, ist also schön skalierbar. In wie weit stellt ein SAN einen Single Point of failure dar ? Ich habe mir den HP MSA 2000 fc G2 ausgesucht. Der hat redundante I/O-Module, redundante Lüfter und Netzteile, und die Platten werden natürlich als RAID 5 konfiguriert. Da kann doch eigentlich nicht mehr viel passieren. Wichtig ist in beiden Szenarios, daß eine Live-Migration der VM's zwischen den Nodes möglich ist. Was denkt Ihr ? Irgendwas, was ich übersehen hab' ? Bernd
Moin Bernd, From: "Lentes, Bernd"
Ich möchte ein HA-Cluster mit 2 Nodes aufbauen. 3 Dienste sollen hochverfügbar sein, jeweils Webanwendungen mit einer Datenbank, später eventl. auch mehr. Ich will mit KVM für jeden Dienst eine VM bauen. Bleibt ein Node stehen, sollen auf dem anderen Node die VM's starten. Damit habe ich 1-2 Minuten Downtime, damit kann ich leben.
hier könntest Du die Downtime weit geringer halten, indem Du die Ersatz VM bereits gestartet vorhältst (bei DRBD sogar nötig) und nur noch die IP für die Clients aufschaltest, wenn die Haupt Node ausfällt.
Ich überlege, ob ich den Speicherplatz für die VM's als DRBD oder als Fibrechannel SAN zur Verfügung stellen soll.
Für mich sind das zwei paar Stiefel. Die Frage sollte wohl eher sein, ob Du DAS, oder SAN einsetzt. Ich persönlich setze wegen der Skalierbarkeit SANs ein, was nicht heißt, daß man auf DRBD verzichten muß.
Der Speicherplatz wird den VM's als nackte, unformatierte Partition zur Verfügung gestellt, das soll schneller sein als eine Imagedatei.
DRBD hat für mich den Vorteil, daß es billiger ist ( ca. 6000,-- € weniger ). Ein SAN hat den Vorteil, daß ich damit auch noch anderen Servern Speicherplatz zur Verfügung stellen kann, ist also schön skalierbar. In wie weit stellt ein SAN einen Single Point of failure dar ? Ich habe mir den HP MSA 2000 fc G2 ausgesucht. Der hat redundante I/O-Module, redundante Lüfter und Netzteile, und die Platten werden natürlich als RAID 5 konfiguriert. Da kann doch eigentlich nicht mehr viel passieren.
Ich habe mit den MSA1500 angefangen und es funktioniert, aber ich bin von der Performance dieser Systeme nicht begeistert und setze hier auf andere Hersteller, z.B. Infortrend. Persönlich würde ich Dir hier eher zu einfachen SANs raten und dafür lieber zwei davon mit DRBD sychronisieren.
Wichtig ist in beiden Szenarios, daß eine Live-Migration der VM's zwischen den Nodes möglich ist.
Was denkt Ihr ? Irgendwas, was ich übersehen hab' ?
Das Handling für die Datenbanken solltest Du Dir genau vorher überlegen, die VMs und Platten zu moven sollte gar kein Problem sein. Just my2cents Daniel -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Daniel Bauer schrieb:
hier könntest Du die Downtime weit geringer halten, indem Du die Ersatz VM bereits gestartet vorhältst (bei DRBD sogar nötig) und nur noch die IP für die Clients aufschaltest, wenn die Haupt Node ausfällt.
Wieso ist das bei DRBD nötig ? Und wie schalte ich von einem CRM wie pacemaker die IP auf die andere VM ? Der Ressource Agent für VM's (VirtualDomain) kennt dafür keine Möglichkeit. Und wenn ich beide VM's mit einem SAN laufen habe, brauche ich doch ein Cluster-aware Filesystem, oder ? Ich möchte aber gerne die VM's in nackte Partitionen instaliieren, habe also gar kein FS.
Das Handling für die Datenbanken solltest Du Dir genau vorher überlegen
Was meinst Du damit ? Bernd-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
From: "Lentes, Bernd"
Daniel Bauer schrieb:
hier könntest Du die Downtime weit geringer halten, indem Du die Ersatz VM bereits gestartet vorhältst (bei DRBD sogar nötig) und nur noch die IP für die Clients aufschaltest, wenn die Haupt Node ausfällt.
Wieso ist das bei DRBD nötig ?
bei DRBD hast Du ein Master und ein Slave Device, die sich ständig synchronisieren müssen (= Raid 1 übers LAN). Wenn Deine Slave VM down ist, wohin soll dann der Master die Daten synchronisieren?
Und wie schalte ich von einem CRM wie pacemaker die IP auf die andere VM ? Der Ressource Agent für VM's (VirtualDomain) kennt dafür keine Möglichkeit.
Ich kann Dir zum CRM nicht viel sagen, aber letztlich muß sobald der Master down ist, der Slave die IP Adresse übernehmen (ifconfig IP up) und das CRM gestartet werden. Das sollte mit jedem Dienst funktionieren ...
Und wenn ich beide VM's mit einem SAN laufen habe, brauche ich doch ein Cluster-aware Filesystem, oder ? Ich möchte aber gerne die VM's in nackte Partitionen instaliieren, habe also gar kein FS.
Ohne FS dürfte nichts gehen, wenn doch, ändert dies an der Sache nichts, aber deswegen brauchst Du kein Cluster FS. Bei mir können beide Systeme auf die Platte (ext4) im SAN zugreifen (aber nicht gleichzeitig mounten). Der Master hat die Partition gemountet, wenn dieser nun down ist, ist die Partition wieder frei und der Slave kann diese mounten. Das läuft wie oben bei der IP Adresse und sollte als erstes gemacht werden, ungefähr so: 1. Master down 2. mount Datenpartition 3. evtl. Datenbankupdate / -konsistenzprüfung 4. ifconfig IP up 5. Dienste (CRM) starten
Das Handling für die Datenbanken solltest Du Dir genau vorher überlegen
Was meinst Du damit ?
Siehe oben, Punkt 3. Wenn der Server heruntergefahren wird, ist die Datenbank sicherlich in Ordnung, wenn der Rechner aber abstürzt ... in welchen Zustand ist sie dann? Wenn Du mit DRBD arbeitest und die Datenbank auf dem DRBD Device ist und während der Synchronisation was schief geht, was ist dann mit der Datenbank? Das sind meine Befürchtungen ... Prinzipiell kannst Du natürlich auch die VM auf dem SAN nur einmal vorhalten und jedes mal komplett starten, somit hast Du nach dem Down der VM auf dem Master den kompletten Startvorgang der VM auf dem Slave abzuwarten. Mit DRBD funktioniert das wahrscheinlich auch, indem Du den DRBD auf den Hostnodes laufen läßt, IMHO funktioniert das aber nur mit Dateisystemen die in der Instanz verfügbar sind; Du willst ja mit physichen Devices arbeiten, die nicht in der verwalteten Instanz verfügbar sind. Gruß Daniel -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Daniel Bauer schrieb:
bei DRBD hast Du ein Master und ein Slave Device, die sich ständig synchronisieren müssen (= Raid 1 übers LAN). Wenn Deine Slave VM down ist, wohin soll dann der Master die Daten synchronisieren?
Auf die Festplatte. Ich will den DRBD auf den nodes laufen lassen, nicht in den VM's.
Und wie schalte ich von einem CRM wie pacemaker die IP auf die andere VM ? Der Ressource Agent für VM's (VirtualDomain) kennt dafür keine Möglichkeit.
Ich kann Dir zum CRM nicht viel sagen, aber letztlich muß sobald der Master down ist, der Slave die IP Adresse übernehmen (ifconfig IP up) und das CRM gestartet werden. Das sollte mit jedem Dienst funktionieren ...
Das CRM läuft permanent auf den nodes. CRM = Cluster Resource Management
Mit DRBD funktioniert das wahrscheinlich auch, indem Du den DRBD auf den Hostnodes laufen läßt, IMHO funktioniert das aber nur mit Dateisystemen die in der Instanz verfügbar sind; Du willst ja mit physichen Devices arbeiten, die nicht in der verwalteten Instanz verfügbar sind.
DRBD repliziert auch nackte Partitionen ohne FS: http://lists.linbit.com/pipermail/drbd-user/2011-January/015318.html Bernd-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lentes, Bernd [24.01.2011 11:45]:
Daniel Bauer schrieb:
bei DRBD hast Du ein Master und ein Slave Device, die sich ständig synchronisieren müssen (= Raid 1 übers LAN). Wenn Deine Slave VM down ist, wohin soll dann der Master die Daten synchronisieren?
Auf die Festplatte. Ich will den DRBD auf den nodes laufen lassen, nicht in den VM's.
Hallo Bernd, nimm doch zwei Hosts mit Xen, dazu ein SAN, auf dem die VMs liegen. Mit Pacemaker testen die Hosts, wer dran ist... Dazu hat ein gewisser Herr Schwartzkopff ein interessantes Buch geschrieben: http://www.oreilly.de/catalog/linuxhacluster2ger/ Dort ist z. B. beschrieben,
Und wie schalte ich von einem CRM wie pacemaker die IP auf die andere VM ?
:-) Ein Probekapitel (Installation - bis hin zum ersten Spielcluster, bei dem sich die Hosts die IPs zuschieben) ist online verfügbar. Alternativ kannst Du Dir die Citrix-Xen-Lösung ansehen, die haben wir hier im Einsatz. Die aktuelle Version kann wohl immer noch keinen gemeinsamen Zugriff zweier VMs auf ein Datenvolumen, aber das ist ja auch nicht gefordert. Als Failoverlösung läuft es bei uns. Und man kann Support kaufen - wenn das bei euch eine Rolle spielt... Nachteil: die Citrix-Kommandozentrale läuft nur unter Windows :-\ Gruß Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk09XQ0ACgkQk33Krq8b42MxwACeKWdu3c+PFIoDK9f5HBMoEB2g 3XIAnj6+bRGicvMXcqPG3KEglY0ewmR8 =cCpF -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Werner Flamme schrieb:
Hallo Bernd,
nimm doch zwei Hosts mit Xen, dazu ein SAN, auf dem die VMs liegen. Mit Pacemaker testen die Hosts, wer dran ist... Dazu hat ein gewisser Herr Schwartzkopff ein interessantes Buch geschrieben: http://www.oreilly.de/catalog/linuxhacluster2ger/
Dort ist z. B. beschrieben,
Das Buch habe ich bereits. XEN wollte ich nicht nehmen, da es dazu eines Extra-Kernels bedarf. KVM ist im Vanilla-Kernel ab 2.6.20 integriert.
Und wie schalte ich von einem CRM wie pacemaker die IP auf die andere VM ?
:-) Ein Probekapitel (Installation - bis hin zum ersten Spielcluster, bei dem sich die Hosts die IPs zuschieben) ist online verfügbar.
Alternativ kannst Du Dir die Citrix-Xen-Lösung ansehen, die haben wir hier im Einsatz. Die aktuelle Version kann wohl immer noch keinen gemeinsamen Zugriff zweier VMs auf ein Datenvolumen, aber das ist ja auch nicht gefordert. Als Failoverlösung läuft es bei uns. Und man kann Support kaufen - wenn das bei euch eine Rolle spielt... Nachteil: die Citrix-Kommandozentrale läuft nur unter Windows :-\
Die Citrix-Lösung ist aber eine bare-metal Lösung, oder ? Ich würde eigentlich gerne SLES 11 nehmen, da kann ich mit den nodes noch andere Sachen machen. Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lentes, Bernd [24.01.2011 12:42]:
Werner Flamme schrieb:
Hallo Bernd,
nimm doch zwei Hosts mit Xen, dazu ein SAN, auf dem die VMs liegen. Mit Pacemaker testen die Hosts, wer dran ist... Dazu hat ein gewisser Herr Schwartzkopff ein interessantes Buch geschrieben: http://www.oreilly.de/catalog/linuxhacluster2ger/
Dort ist z. B. beschrieben,
Das Buch habe ich bereits. XEN wollte ich nicht nehmen, da es dazu eines Extra-Kernels bedarf. KVM ist im Vanilla-Kernel ab 2.6.20 integriert.
Der Xen-Kernel wird in der Dom0 zusätzlich zum default-Kernel installiert. Der einzige bemerkbare Unterschied ist, dass die Grafikkarte dann nur noch im Standard-VGA-Modus läuft, was bei Servern ja keinen Unterschied machen sollte :-) Mir ist bis jetzt nichts untergekommen, was einen Vanilla-Kernel erfordert, bis jetzt lief alles mit Xen. Insofern weiß ich nicht, warum ich einen Vanilla-Kernel bevorzugen sollte. Support habe ich mit allen Kernels, die Novell absondert. [...]
Die Citrix-Lösung ist aber eine bare-metal Lösung, oder ? Ich würde eigentlich gerne SLES 11 nehmen, da kann ich mit den nodes noch andere Sachen machen.
Das willst Du nicht. Du willst alle Dienste in eine oder mehrere VMs auslagern. Wenn auf dem Host ein Dienst Amok läuft, legt er den Host lahm. Läuft er in einer VM Amok, sind die Auswirkungen wesentlich leichter zu beherrschen. SLES 11 erfordert übrigens für HA noch das/den HA Extension Pack. Schon wenn man ein OCFS2-Volume haben möchte, auch ohne dass man Sachen wie DRBD oder Pacemaker will. Ja, Citrix ist bare metal. Man braucht übrigens 1 SLES-Lizenz je Blech, egal ob man mit SLES oder z. B. VMWare virtualisiert, habe ich erfahren... Gruß Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk09a/4ACgkQk33Krq8b42MFcACdH2NLO06+mfREZBckovUKCqJE 2M8AnjXux3s5KG63E2nuGA1QfFDFYvju =ANwi -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Werner Flamme schrieb am 24.01.2011 13:09 Uhr:
Man braucht übrigens 1 SLES-Lizenz je Blech, egal ob man mit SLES oder z. B. VMWare virtualisiert, habe ich erfahren... "je Blech" ist IMHO soweit richtig. Aber wenn man nur ein "Blech" auf dem SLES als (XEN-)Wirt läuft, ist es egal wie viele (XEN-)SLES-Gäste darauf laufen. Ob das mit KVM auch so ist, weiß ich jetzt nicht.
Das ist der Grund warum hier demnächst mit SLES selbst virtualisiert werden soll, statt mit einem extra Bare Metal Hypervisor, weil letzeres bezüglich Lizenzen die wesentlich teurere Variante wäre. Gruß Marc -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marc Patermann [24.01.2011 14:59]:
Hallo,
Werner Flamme schrieb am 24.01.2011 13:09 Uhr:
Man braucht übrigens 1 SLES-Lizenz je Blech, egal ob man mit SLES oder z. B. VMWare virtualisiert, habe ich erfahren...
"je Blech" ist IMHO soweit richtig. Aber wenn man nur ein "Blech" auf dem SLES als (XEN-)Wirt läuft, ist es egal wie viele (XEN-)SLES-Gäste darauf laufen. Ob das mit KVM auch so ist, weiß ich jetzt nicht.
Hat mir Novell so gesagt, ohne sich auf eine Virtualisierungslösung zu beziehen. Allerdings war die Kombination SLES/KVM von SAP vor einem Jahr noch nicht supported (ist es wohl immer noch nicht), und deshalb hatte ich nur wg. Xen und VMWare angefragt.
Das ist der Grund warum hier demnächst mit SLES selbst virtualisiert werden soll, statt mit einem extra Bare Metal Hypervisor, weil letzeres bezüglich Lizenzen die wesentlich teurere Variante wäre.
Wesentlich... nunja. Wie auch immer, hatte ich ja ursprünglich selbst vor, bevor ich auf "SLES unter VMWare ESX" gedrängt wurde ;-) Gruß Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk09iPgACgkQk33Krq8b42NCRwCfdALPni97FiidzRgUD0yEnpnV ptkAniZfddEnYT79LBH5Wk9jWPrwWFn7 =Es/V -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
From: "Lentes, Bernd"
Daniel Bauer schrieb:
Ich kann Dir zum CRM nicht viel sagen, aber letztlich muß sobald der Master down ist, der Slave die IP Adresse übernehmen (ifconfig IP up) und das CRM gestartet werden. Das sollte mit jedem Dienst funktionieren ...
Das CRM läuft permanent auf den nodes. CRM = Cluster Resource Management
ok, ich dachte dabei eher an Customer Relationship Management ...
Mit DRBD funktioniert das wahrscheinlich auch, indem Du den DRBD auf den Hostnodes laufen läßt, IMHO funktioniert das aber nur mit Dateisystemen die in der Instanz verfügbar sind; Du willst ja mit physichen Devices arbeiten, die nicht in der verwalteten Instanz verfügbar sind.
DRBD repliziert auch nackte Partitionen ohne FS: http://lists.linbit.com/pipermail/drbd-user/2011-January/015318.html
das ist in der Tat sehr schön, denn damit funktioniert es auch mit DRBD auf den Nodes, trotzdem halte ich ein SAN für geeigneter, da es skalierbarer ist und Dein Vorhaben mit DRBD dort genauso realisierbar ist, wie über DAS. Gruß Daniel -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (4)
-
Daniel Bauer
-
Lentes, Bernd
-
Marc Patermann
-
Werner Flamme