Archiv verlassen und diese Seite im Standarddesign anzeigen : DRBD/Heartbeat wirklich für Firmeneinsatz geeignet?
Hallo zusammen,
zwei verschiedene Firmen haben uns eher davon abgeraten, DRBD/Heartbeat für Redundanz/Hochverfügbarkeit zu verwenden, sondern ein shared storage auf Fiberchannel-Basis zu verwenden, da ".. daß schneller sei und natürlich dann im Support enthalten. Außerdem würde DRBD für unseren Einsatz mit vielen kleinen Dateien nicht gut geeignet sein...".
Das mit dem Support ist klar, aber ist das aus technischer Sicht wahr?
Wenn ich mich so im Internet umsehe, finde ich regelmäßig Beiträge zu Clustern mit DRBD an Unis, jedoch sehr wenig aus Unternehmensbereichen, auch wenn Linbit(Firma des DRBD-Entwicklers) einige, eher unbekannte, Firmen aufführt.
Laut einem der beiden Consultants würde ein DRBD-Laufwerk auf zwei geshare'ten modernen lokalen Dateisystemen/Festplatten nur schwer über 30MB/s Transferrate kommen, weshalb das für performante Systeme und gerade XEN mit virtuellen Maschinen nicht ausreichend sei.
Das Problem hierbei für mich ist natürlich nun, daß ich das selbst im Lab nicht testen kann, denn wir haben keine hochwertigen Systeme zum Testen, die annähernd an die Leistungsfähigkeit unseres Zielsystemes herankommen würden.
Ich denke, es stehen dabei zwei Systeme im Vergleich:
1. zwei Server die an einer "shard storage" hängen, alles aus einer Hand (HP, IBM, was-auch-immer,..)
2. zwei Server mit vier lokalen Festplatten, RAID10 darauf und DRBD per Crossover an GB-Interfacen darüber.
Wir möchten vor allem Hochverfügbarkeit. Leistung ist sekundär, das System wird ein XEN welches Postfix, MySQL und Apache beheimaten wird, also viele kleine Schreib- und Lesevorgänge, kaum große Dateien.
Wer hat so weit DRBD Erfahrung, daß er mir vielleicht den ein oder anderen Hint zur Entscheidung geben kann?
Grüße und Danke, Florian
zwei verschiedene Firmen haben uns eher davon abgeraten, DRBD/Heartbeat für Redundanz/Hochverfügbarkeit zu verwenden, sondern ein shared storage auf Fiberchannel-Basis zu verwenden, da ".. daß schneller sei und natürlich dann im Support enthalten. Außerdem würde DRBD für unseren Einsatz mit vielen kleinen Dateien nicht gut geeignet sein...".
Das würde ich so unterschreiben.
Laut einem der beiden Consultants würde ein DRBD-Laufwerk auf zwei geshare'ten modernen lokalen Dateisystemen/Festplatten nur schwer über 30MB/s Transferrate kommen, weshalb das für performante Systeme und gerade XEN mit virtuellen Maschinen nicht ausreichend sei.
Das mit den 30 MB/s kann ich nachvollziehen, da dein Bottleneck das Netzwerk ist. Die Frage die du dir stellen solltest: Wieviele Leistung braucht mein XEN System, gerade wenn es I/O intensiv ist (viele kleine, random Write und Read I/Os)
Das Problem hierbei für mich ist natürlich nun, daß ich das selbst im Lab nicht testen kann, denn wir haben keine hochwertigen Systeme zum Testen, die annähernd an die Leistungsfähigkeit unseres Zielsystemes herankommen würden.
Das ist schlecht. Ohne Tests, selbst mit kleinerer Hardware die man dann hochrechnen könnte, wird eine Aussage über die Performance schwer.
Was habt ihr denn für ein Budget? Wie sollten die DRBD/Heartbeat ausgestattet sein, was für Platten?
Tja.. Wir wollen für ca. 15k € ein redundantes System, also entweder zwei plattenlose Server + ein Storage, oder zwei Maschinen mit lokalem Software-Raid und drbd/Heartbeat.
Die Storage-Variante ist noch nicht konkretisiert, die drbd-Variante könnte folgendermaßen aussehen:
2x HP DL385 erstmal mit einem Dualcore, aber 4 GB RAM
jeweils zwei GB-Interface, davon eines dann per CrossOver miteinander verbunden zwecks DRBD/Heartbeat.
4 lokale Platten als RAID 1+0 ;) (Die Raid-Diskussion hatten wir ja bereits wegen Monitoring, dieses System ist ähnlich, nur das hier nun "echte" Serverhardware zum Einsatz kommt)
Das macht für mich auf beiden Seiten ein schnelles Software RAID und diese dann über Gigabit-Interface gekoppelt... Das sollte doch, trotz kleiner IOs, schnell genug sein?!
Grüße, Florian
Tja.. Wir wollen für ca. 15k € ein redundantes System, also entweder zwei plattenlose Server + ein Storage, oder zwei Maschinen mit lokalem Software-Raid und drbd/Heartbeat.
Für 15.000 € sollte sich auch ein HP DL380 G4 Packaged Cluster mit einer MSA500 realisieren lassen. Alternativ, Packaged Cluster mit MSA1000. Das System ist für Cluster gedacht und wird als Paket angeboten. RHEL und SLES werden supported.
Die Storage-Variante ist noch nicht konkretisiert, die drbd-Variante könnte folgendermaßen aussehen:
2x HP DL385 erstmal mit einem Dualcore, aber 4 GB RAM
jeweils zwei GB-Interface, davon eines dann per CrossOver miteinander verbunden zwecks DRBD/Heartbeat.
4 lokale Platten als RAID 1+0 ;) (Die Raid-Diskussion hatten wir ja bereits wegen Monitoring, dieses System ist ähnlich, nur das hier nun "echte" Serverhardware zum Einsatz kommt)
Ich würde noch eine weitere NIC mit reinsetzen, wegen Teaming zum Netzwerk hin (Performance + Redundanz) und die dritte Gigabit-Strecke für DRBD.
Das macht für mich auf beiden Seiten ein schnelles Software RAID und diese dann über Gigabit-Interface gekoppelt... Das sollte doch, trotz kleiner IOs, schnell genug sein?!
Vergiss das Software-RAID in dieser Konstellation: Spendier dem ProLiant lieber 512 MB BBWC für den Smart-Array und vier schnelle 15k Platten. Das RAID 1+0 macht der Smart-Array von sich aus.
Ich entnehme deiner Antwort jetzt mal, daß du ein gemeinsames Storage nicht als gefährlichen "SinglePointOfFailure" siehst?
naja, das Ding wird ja nicht gerade eine externe USB-Platte mit einem Steckernetzteil sein, oder?
In der Liga sind redundaten Anschlüsse für Controller und Strom sowie entsprechende RAID-Level und Hotspares ja durchaus "üblich". Klar ist es trotzdem eine Art SPOF - je nach dem, wie paranoid ihr seid...
naja, das Ding wird ja nicht gerade eine externe USB-Platte mit einem Steckernetzteil sein, oder?
In der Liga sind redundaten Anschlüsse für Controller und Strom sowie entsprechende RAID-Level und Hotspares ja durchaus "üblich". Klar ist es trotzdem eine Art SPOF - je nach dem, wie paranoid ihr seid...
Sagen wir mal andersrum: 99.999% :eek::ugly:
Sonst würd mir ja ein Server mit eingebautem SAS-Raid vollauf langen...
Sagen wir mal andersrum: 99.999% :eek::ugly:
Erreichst du mit der Hardware nicht. Willkommen in der Welt von OpenVMS, Mainframes und HP NonStop.
Sonst würd mir ja ein Server mit eingebautem SAS-Raid vollauf langen...
HA != HA. You get what you pay for, und performat 99,999% zu erreichen, kostet richtig Geld. Jede Neun nach dem Komma kostet Geld, also mach es mal locker. Ich habe in meinem Berufsleben mehr als eine HA-Umgebung hochgezogen und das zuvorgesagte wurde immer wieder eindrucksvoll unter Beweis gestellt.
Klar, 99,999% kann man auch mit Standardhardware und OSS schaffen - aber wie realistisch ist das?? 99,999% kann auch heißen das die Kiste an 364 Tagen im Jahr down ist, aber wenn sie den 365. Tag durchläuft eine Verfügbarkeit von 100% hat. Wir reden hier immerhin von ungeplanter Downtime und geplanter Downtime. Die die 99,999% fließt nur die ungeplante Downtime ein.
Ok, also sieht es so aus, als ob wir statt Software besser auf Hardware setzen sollten.
Dann muß ich mir "nur" noch was für die Ausfallsicherheit des Storage einfallen lassen...
Wo erschließt sich mir eigentlich, welchen Level der Verfügbarkeit ich in Hardware habe?
Angenommen, wir nehmen zwei DL385er und ein dazu passendes Storage, woher weiß ich dann, ob ich 99%, 99,9% oder 99,99% theoretische Verfügbarkeit habe?
Anhand der Angaben der einzelnen Geräte? Und wie rechne ich das dann zusammen? Serielle Verfügbarkeit multipliziere ich wahrscheinlich, aber parallele?
Gibt's dazu vielleicht einen guten Link?
Grüße, Florian
Dann muß ich mir "nur" noch was für die Ausfallsicherheit des Storage einfallen lassen...
Kleinste Variante dafür:
2x EVA4000 2C1D 8x Platten + 2x 1 TB CA Lizenz
4x B-Series 4/8 FC-Switches
Wo erschließt sich mir eigentlich, welchen Level der Verfügbarkeit ich in Hardware habe?
Angenommen, wir nehmen zwei DL385er und ein dazu passendes Storage, woher weiß ich dann, ob ich 99%, 99,9% oder 99,99% theoretische Verfügbarkeit habe?
Anhand der Angaben der einzelnen Geräte? Und wie rechne ich das dann zusammen? Serielle Verfügbarkeit multipliziere ich wahrscheinlich, aber parallele?
Gibt's dazu vielleicht einen guten Link?
Einen Link dafür kenne ich nicht. Spontan über Google gefunden: Link (http://www.tecchannel.de/index.cfm?pid=315&pk=430342&p=7)
Beschreibe bitte genau dein Anforderungsprofil:
Was genau soll auf dem HA System an Diensten angeboten werden.
Was kosten Ausfälle pro Stunde.
99.999% rechnen sich selten.
mfg
cane
Beschreibe bitte genau dein Anforderungsprofil:
Was genau soll auf dem HA System an Diensten angeboten werden.
Was kosten Ausfälle pro Stunde.
XEN Gäste für ein Nagios-Monitoring. Wenn daran keine teuren SLAs beim Kunden hängen, sind 99,99% überkandidelt. Da tun es auch 99% - und die schaffe ich mit guter Hardware problemlos - die Verfügbarkeit der Software ist eine andere Sache.
XEN Gäste für ein Nagios-Monitoring..
HALT!!
Missverständnis, das Monitoring ist eine extra-Geschichte!
DIese Maschine wird der wichtigste Mail/MySQL/Web-Server in unserem Hause, wobei Web sich nur auf ein kleines, aber frequentiertes Portal bezieht.
Die Last wird eher gering, jedoch ist der Mailverkehr in seiner Auswirkung nicht zu unterschätzen, da jede angenommen Email gegen Mysql geprüft wird.
Im Moment ist ein 2.400er Xeon(Vmware ESX, drei Maschinen) zu 40% ausgelastet. Diesen möchten wir nun migrieren.
Uns ist vor allem Anderen die Verfügbarkeit wichtig, Rechenleistung mit aktuellen Dualcore-Systemen sollte die nächsten zwei Jahre reichen und dann klemmen wir nen zweiten rein ;)
Xen ist unsere Wahl um auch mal parallel z.B. ein Mysql-Update hochzuziehen als weiteres Image und dann im Live-Betrieb zu schwenken, ohne diesen zu beeinflussen, daß fanden wir bei VmWare schon spitze, nur das einen da die Lizenzkosten ... naja :ugly:
Nein, das Entscheidende ist nur die Verfügbarkeit, denn ein Ausfall dieses Systemes betrifft sowohl alle Business- als auch alle Privatkunden. Das können wir uns nicht (mehr) leisten, weshalb wir auf so "lustige" Ideen wie Heartbeat/DRBD kommen, denn leider haben wir erstmal kein großartiges Budget (wie gesagt, ca. 15k €)
...
Davon mal ab: JA, der Nagios bräuchte keine 99,999%, der kann auch weniger verkraften ;)
Im Übrigen sind diese 99,999% eine Zahl, mit der mir mein Chef "in den Ohren" liegt, da das ja "Provider-Level" sei und wir das somit auch brauchen...
Ich sag mal so, ich muß den Kopf halt hinhalten, egal welche Zahl da steht ....:rolleyes:
Grüße, Florian
HALT!!
Missverständnis, das Monitoring ist eine extra-Geschichte!
Ah, okay. Hab ich falsch verstanden.
DIese Maschine wird der wichtigste Mail/MySQL/Web-Server in unserem Hause, wobei Web sich nur auf ein kleines, aber frequentiertes Portal bezieht.
Die Last wird eher gering, jedoch ist der Mailverkehr in seiner Auswirkung nicht zu unterschätzen, da jede angenommen Email gegen Mysql geprüft wird.
Im Moment ist ein 2.400er Xeon(Vmware ESX, drei Maschinen) zu 40% ausgelastet. Diesen möchten wir nun migrieren.
Warum nicht bei VMware bleiben?
Xen ist unsere Wahl um auch mal parallel z.B. ein Mysql-Update hochzuziehen als weiteres Image und dann im Live-Betrieb zu schwenken, ohne diesen zu beeinflussen, daß fanden wir bei VmWare schon spitze, nur das einen da die Lizenzkosten ... naja :ugly:
You get what you pay for....
Nein, das Entscheidende ist nur die Verfügbarkeit, denn ein Ausfall dieses Systemes betrifft sowohl alle Business- als auch alle Privatkunden. Das können wir uns nicht (mehr) leisten, weshalb wir auf so "lustige" Ideen wie Heartbeat/DRBD kommen, denn leider haben wir erstmal kein großartiges Budget (wie gesagt, ca. 15k €)
Wie ich oben schon mal sagte: Verfügbarkeit kostet Geld.
Im Übrigen sind diese 99,999% eine Zahl, mit der mir mein Chef "in den Ohren" liegt, da das ja "Provider-Level" sei und wir das somit auch brauchen...
Don't play with the big boy... jede Neun nach dem Komma kostet Geld, und wenn ich Enterprise haben will, dann muss ich Enterprise auch bezahlen können. Eine Lektion die man leider mal gelernt haben muss.
15.000 € Budget sind ein Anfang, aber ich kann mir nicht denken wie ich damit 99,999% erreichen will, also five nines, five minutes. Hochverfügbarkeit fängt bei 99,99% an. Das entspricht 8 Stunden !!ungeplanter!! Downtime im Jahr. Das kann man mit 15.000 € sehr gut erreichen. Für mehr ist auch mehr Geld notwendig - und auch die Infrastruktur. 99,999% erreichst du nicht mit einem Servercluster, gespiegelten Storage-Systemen in einem Brandabschnitt - da muss schon ein zweiter, separater Brandabschnitt oder ein anderes RZ her. ;) 99,999% heißt auch "nur" Fault Resistant - Disaster Tolerant entspricht 99,999999%. Das verfügbarste System was ich kenne, sind HP NonStop - die garantieren die 99,9999% Verfügbarkeit - zu einem stolzen Preis.
Ok, danke nochmal ;)
Meine Lernkurve in diesem Thread ist beeindruckend, das gefällt mir!
Dann werden wir wohl auf ein "99,99%"-System satteln, wie unser Budget ja schon ansagt.
Das mit dem seperaten RZ kommt dann nächstes Jahr :)
Das vorhandene VmWare ist nicht mehr gültig, daher müßten wir eine volle Lizenz kaufen, die sich gewaschen hat (>6k €). Das ist ja schon unser halbes Server-Budget (fast), außerdem haben wir nur Linux-Systeme, also ist VmWare eigentlich schon zu "groß", wir könnten auch problemlos auf Virtuozzo satteln, XEN gefällt mir aufgrund der Architektur etwas besser, da eine klarere und stabilere Trennung der Guests vorhanden ist.
So long, Florian
Die Last wird eher gering, jedoch ist der Mailverkehr in seiner Auswirkung nicht zu unterschätzen, da jede angenommen Email gegen Mysql geprüft wird.
Von wievielen Mails / Minute reden wir?
Ich würde an deiner Stelle 2x DL 385 mit je 2x DC Opterons, 8 GB RAM, schnellen Platten und komplett redundanten Komponenten anschaffen + 2 ESX Lizenzen.
Auf der Hardware kannst Du locker 10 - 20 VMs rennen lassen, als Renewal (Hardware kommt oft aus Projekt / Messeeinsatz und hat volle 3 jahre NBD Garantie )wirst Du ohne die ESX Lizenzen deutlich unter 10k bleiben.
Da Du für den ESX weder HA noch andere Sachen zwingend benötigst reicht dir die ESX Starter Edition.
So bleibst Du im Budget und hast eine sehr solide und qualitativ hochwertige hardwarebasis auf der Du massig Produktiv- und Test-Maschinen betreiben kannst.
Wenn Du dir zusätzlich zum daily Backup der Daten die kompletten VMs ab und an websicherst kannst Du auch bei Totalausfall von Hardware die wichtigsten VMs ratzefazz wieder auf dem anderen Server restoren.
So ähnlich wie hier beschrieben baue ich übrigens meine Produktivumgebungen auf...
mfg
cane
Ja, aber wozu ESX wenn's XEN oder Virtuozzo auch tun? Ich sehe da keinen entscheidenden Vorteil außer dem, das ESX HA unterstützen könnte, was wir uns aber, wie du schon erkannt hast, nicht leisten werden...
Im Übrigen reden wir von einigen hundert Mails pro Sekunde, da langt schon ein Opteron pro Maschine ;)
Was mich immer noch an diesem Konzept stört ist, daß ich nicht ohne weiteres ein direktes Failover habe. Das wiederum gefällt mir ja so an DRBD/Heartbeat, wo auf beiden "Seiten" XEN läuft und die Image-Inhalte gespiegelt sind, so daß bei einem Ausfall sofort die zweite Maschine übernimmt und loslegt.
Ich habe gehört, daß das sogar mit laufenden SSH-Sitzungen funktionieren soll, man merkt also nicht mal auf ssh-Ebene, daß man plötzlich auf einer anderen physikalischen Maschine ist! Das hatte mich dann doch beeindruckt.. :cool:
Naja, ich lerne weiter, heute kommt nochmal eine Consulting-Firma, mal sehen, was die uns dazu erzählen...
Grüße, Florian
Was mich immer noch an diesem Konzept stört ist, daß ich nicht ohne weiteres ein direktes Failover habe. Das wiederum gefällt mir ja so an DRBD/Heartbeat, wo auf beiden "Seiten" XEN läuft und die Image-Inhalte gespiegelt sind, so daß bei einem Ausfall sofort die zweite Maschine übernimmt und loslegt.
Sowas schon mal in Betrieb gesehen? Irgendwie beschleicht mich das Gefühl das dieses Konzept nicht funktioniert.
Ja, aber wozu ESX wenn's XEN oder Virtuozzo auch tun? Ich sehe da keinen entscheidenden Vorteil außer dem, das ESX HA unterstützen könnte, was wir uns aber, wie du schon erkannt hast, nicht leisten werden...
Von welcher XEN Version reden wir?
Ich weiss nicht ob ich für solch ein relevantes system die OpenSource Version eines so jungen Projektes wie XEN nutzen würde.
Bei den kommerziellen XEN-Versionen hättest Du IMO die Wahl zwischen Enterprise und Express, wobei Enterprise wohl geeigneter wäre, preislich auch definitiv im Rahmen.
Was mich immer noch an diesem Konzept stört ist, daß ich nicht ohne weiteres ein direktes Failover habe. Das wiederum gefällt mir ja so an DRBD/Heartbeat, wo auf beiden "Seiten" XEN läuft und die Image-Inhalte gespiegelt sind, so daß bei einem Ausfall sofort die zweite Maschine übernimmt und loslegt.
Dann brauchst Du doch eine zentrale Storage... Die dann auch redundant sein muss, sonst hast Du ein richtiges Problem wenn diese ausfällt...
mfg
cane
Dann brauchst Du doch eine zentrale Storage... Die dann auch redundant sein muss, sonst hast Du ein richtiges Problem wenn diese ausfällt...
Nope, dafür is das DRBD dabei. Das übernimmt das spiegeln der Daten auf den anderen Host. Ich habe mal von einer Lösung mit VMware GSX Server und Veritas Replication Exec gelesen. Das spiegeln von sowas klappt, aber der Gast läuft natürlich auf der anderen Seite nicht. Der muss das schon gestartet werden. Das wäre dann bei DRBD/Heartbeat/XEN auch so. Datenverlust gibt es bei einem Hardwarefehler auf jeden Fall, von Softwarefehlern will ich hier gar nicht reden.
drunkenPenguin
02.07.07, 20:27
Hallo,
Wir setzen DRBD in Verbindung mit Heartbeat und Linux Vservern ein.
Mit XEN haben wir in dieser Kombination noch keine Erfahrungen gesammelt.
Los_Andros
02.07.07, 21:48
Ja, aber wozu ESX wenn's XEN oder Virtuozzo auch tun? Ich sehe da keinen entscheidenden Vorteil außer dem, das ESX HA unterstützen könnte, was wir uns aber, wie du schon erkannt hast, nicht leisten werden...
Im Übrigen reden wir von einigen hundert Mails pro Sekunde, da langt schon ein Opteron pro Maschine ;)
Was mich immer noch an diesem Konzept stört ist, daß ich nicht ohne weiteres ein direktes Failover habe. Das wiederum gefällt mir ja so an DRBD/Heartbeat, wo auf beiden "Seiten" XEN läuft und die Image-Inhalte gespiegelt sind, so daß bei einem Ausfall sofort die zweite Maschine übernimmt und loslegt.
Ich habe gehört, daß das sogar mit laufenden SSH-Sitzungen funktionieren soll, man merkt also nicht mal auf ssh-Ebene, daß man plötzlich auf einer anderen physikalischen Maschine ist! Das hatte mich dann doch beeindruckt.. :cool:
Naja, ich lerne weiter, heute kommt nochmal eine Consulting-Firma, mal sehen, was die uns dazu erzählen...
Grüße, Florian
Also ich habe jahrelang IBM Mainframes betreut. Da wurde richtig Asche reingesetzt (Bankenrechenzentrum) und die Mainframe "Cluster" Architektur ist um es so zu sagen "das geilste was es gibt". Da stinken Clusterlösungen im dezentralen Bereich (*nix und Windows basierend) völlig ab.
Aber einen gespiegelten virtuellen Gast laufen lassen .... das Konzept kenne ich aus den IBM Laboren, wo Linux Gäste von VM A nach VM B unterbrechungsfrei verlagert werden. Dafür muß aber der gesamte Content in den Speicher verlagert werden, quasi ein Suspend und dann in das andere VM gespiegelt werden. Dort wird der Speicherzustand wieder aktiviert.
Voraussetzung ist ein shared Storage.
Aber soweit ich weiß geht das noch nicht und wenn ist das durchaus teuer.
.....
aber richtig cool ;)
drunkenPenguin
03.07.07, 05:35
Ja, aber wozu ESX wenn's XEN oder Virtuozzo auch tun? Ich sehe da keinen entscheidenden Vorteil außer dem, das ESX HA unterstützen könnte, was wir uns aber, wie du schon erkannt hast, nicht leisten werden...
Im Übrigen reden wir von einigen hundert Mails pro Sekunde, da langt schon ein Opteron pro Maschine ;)
Was mich immer noch an diesem Konzept stört ist, daß ich nicht ohne weiteres ein direktes Failover habe. Das wiederum gefällt mir ja so an DRBD/Heartbeat, wo auf beiden "Seiten" XEN läuft und die Image-Inhalte gespiegelt sind, so daß bei einem Ausfall sofort die zweite Maschine übernimmt und loslegt.
Ich habe gehört, daß das sogar mit laufenden SSH-Sitzungen funktionieren soll, man merkt also nicht mal auf ssh-Ebene, daß man plötzlich auf einer anderen physikalischen Maschine ist! Das hatte mich dann doch beeindruckt.. :cool:
Naja, ich lerne weiter, heute kommt nochmal eine Consulting-Firma, mal sehen, was die uns dazu erzählen...
Grüße, Florian
Ich verstehe nicht ganz, für was Du das XEN eigentlich brauchst?
Willst Du die Virtualisierungsfunktionen des Prozessors nutzen? Windows laufen lassen?
Wir haben so ein Setup, wie Du es beschreibst, bereits bei einem Kunden realisiert. Allerdings nicht mit XEN, sondern -- wie bereits erwänt -- mit Linux Vservern.
Also ich habe jahrelang IBM Mainframes betreut. Da wurde richtig Asche reingesetzt (Bankenrechenzentrum) und die Mainframe "Cluster" Architektur ist um es so zu sagen "das geilste was es gibt". Da stinken Clusterlösungen im dezentralen Bereich (*nix und Windows basierend) völlig ab.
Falsche Baustelle. Wir reden hier von i386 kompatiblen Servern und du von Mainframes. Das auf Mainframes schon seit 30 Jahren virtualisiert wird, ist mir durchaus klar. Aber das ist nun mal eine andere Welt. Nicht alles was da geht, geht auch im kleineren Maßstab. Bezüglich Clusterlösungen gibt es nur noch zwei Welten die da mithalten, bzw. sogar besser sind:
- OpenVMS
- HP NonStop
Aber einen gespiegelten virtuellen Gast laufen lassen .... das Konzept kenne ich aus den IBM Laboren, wo Linux Gäste von VM A nach VM B unterbrechungsfrei verlagert werden. Dafür muß aber der gesamte Content in den Speicher verlagert werden, quasi ein Suspend und dann in das andere VM gespiegelt werden. Dort wird der Speicherzustand wieder aktiviert.
Voraussetzung ist ein shared Storage.
Das sowas für XEN geplant ist wusste ich, aber nicht wie weit es ist. Mal abwarten. ;)
Los_Andros
03.07.07, 08:45
tjaja, ich weiß,
ich kämpfe ja selber damit auf nicht Enterprise Umgebungen. Ist halt alles noch sehr junge Technik, es wäre wünschenswert wenn da die Entwickler mal über den Tellerrand schauen würden und sich von einigen etablierten Techniken inspirieren würden.
Naja mal sehen :), ich kämpf weiter mit meinem Cluster
Ich möchte XEN einsetzen, um klar voneinander getrennte Linux-Systeme laufen zu lassen. Dabei möchte ich dann ähnliche Systeme nur para-virtualisieren, was mir XEN ja bieten würde..
Das wir dann das kommerzielle XEN einsetzen werden ist abzusehen ;)
Im Moment sind wir nun bei einer HP MS1000 als Storage angekommen, da mir DRBD als Live-System ein zu heißes Eisen zu sein scheint, wohl vor allem, weil Heartbeat nicht immer zuverlässig ist (in der Maillingliste gibt's immer wieder spannende Geschichten bezüglich "Mißverständnissen, weshalb dann heartbeat Dienste auf beiden oder der falschen Seite hochfuhr..").
Somit wird DRBD nun "nur" auf unserem Monitoring-Server kommen, dort können wir uns eine gewisse "Lernphase" erlauben, in der auch mal das System vorübergehend "zickt".
@DrunkenPenguin:
Kannst du deine Aussage, daß ihr drbd einsetzt, mal mit Leben füllen? Was macht ihr mit dem Server? Wie sind Master und Slave technisch verbunden? IO-Performance? Situationen, die dir den Angstschweiß auf die Stirn getrieben haben -> Erfahrungen, die du weitergeben möchtest?
MSA1000 oder 1500? Wieviele Platten? Welche Firmware? Welche Distribution soll als Basis dienen? Welche Switches kommen zum Einsatz?
drunkenPenguin
05.07.07, 00:18
@DrunkenPenguin:
Kannst du deine Aussage, daß ihr drbd einsetzt, mal mit Leben füllen? Was macht ihr mit dem Server? Wie sind Master und Slave technisch verbunden? IO-Performance? Situationen, die dir den Angstschweiß auf die Stirn getrieben haben -> Erfahrungen, die du weitergeben möchtest?
Wir clustern damit vorwiegend Mailserver, Sambaserver, Webserver, und MySQL-Server und haben so etwas bereits für diverse Hochschulen, Firmen und Rechenzentren umgesetzt.
Master u. Slave sind über ein GB-NIC miteinander verbunden, i. d. R. LWL. Zur IO-Performance kann ich nicht viel sagen. Hier sind mal paar Werte, allerdings sind die nicht besonders aussagekräftig, da die jeweiligen NICs, über die das DRBD läuft, über ein normales CAT5 Kabel verbunden sind.
Ich muss dazusagen, dass das ein Softwareraid (RAID 1) mit 4 Dualcore Xeons 2,66 GHz ist; LVM mit 5GB, das DRBD-Device (DRBD 8.0.3) ist mit XFS formatiert. Zum Einsatz kommen 2x 400 GB SATA-Platten über AHCI.
In der Regel verwenden wir aber kein Softwareraid.
Unit information
================
File size = megabytes
Blk Size = bytes
Rate = megabytes per second
CPU% = percentage of CPU used during the test
Latency = milliseconds
Lat% = percent of requests that took longer than X seconds
CPU Eff = Rate divided by CPU% - throughput per cpu load
Sequential Reads
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.6.21-2-vserver-amd64 2000 4096 1 65.23 10.01% 0.060 43.21 0.00000 0.00000 651
2.6.21-2-vserver-amd64 2000 4096 2 120.12 39.97% 0.064 77.53 0.00000 0.00000 300
2.6.21-2-vserver-amd64 2000 4096 4 180.06 78.07% 0.057 267.64 0.00000 0.00000 231
2.6.21-2-vserver-amd64 2000 4096 8 276.33 174.9% 0.052 344.00 0.00000 0.00000 158
Random Reads
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.6.21-2-vserver-amd64 2000 4096 1 12.38 1.901% 0.315 37.70 0.00000 0.00000 651
2.6.21-2-vserver-amd64 2000 4096 2 26.45 6.770% 0.294 17.07 0.00000 0.00000 391
2.6.21-2-vserver-amd64 2000 4096 4 20.12 11.84% 0.485 95.96 0.00000 0.00000 170
2.6.21-2-vserver-amd64 2000 4096 8 22.22 23.88% 0.854 117.54 0.00000 0.00000 93
Sequential Writes
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.6.21-2-vserver-amd64 2000 4096 1 44.53 15.26% 0.059 1499.56 0.00000 0.00000 292
2.6.21-2-vserver-amd64 2000 4096 2 35.32 26.03% 0.137 2015.14 0.00020 0.00000 136
2.6.21-2-vserver-amd64 2000 4096 4 39.36 66.72% 0.250 3310.08 0.00117 0.00000 59
2.6.21-2-vserver-amd64 2000 4096 8 40.25 189.4% 0.473 6083.80 0.00898 0.00000 21
Random Writes
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.6.21-2-vserver-amd64 2000 4096 1 0.93 0.478% 0.007 0.03 0.00000 0.00000 195
2.6.21-2-vserver-amd64 2000 4096 2 0.83 1.232% 0.008 0.03 0.00000 0.00000 67
2.6.21-2-vserver-amd64 2000 4096 4 0.76 2.034% 0.009 0.04 0.00000 0.00000 37
2.6.21-2-vserver-amd64 2000 4096 8 0.55 4.929% 0.018 0.06 0.00000 0.00000 11
Angstschweiss bekommt man wie sonst auch.
Man muss bisschen schauen, dass man z B. nicht beide Seiten zum Primary macht oder nach einer längeren Ausfallzeit alles auf einmal synct. Das erzeugt u. U. zu viel Last, wenn 250 GB oder so rübergeschoben werden.
Ansonsten würde ich bereits von mittleren Oracle-Installationen abraten. Das geht nicht besonders gut, weil das ab einer bestimmten Zugriffszahl pro Sekunde einfach nicht mehr performant genug ist. Da sollte man doch eher auf irgendeine zertifizierte SAN-Lösung mit Fibre Channel und so ausweichen.
edit: bezüglich Heartbeat und Dienste auf der "falschen" Seite hochfahren ... das kenne ich in dieser Form nicht. Wenn das anständig konfiguriert ist, läuft das einwandfrei. Probleme gibt es eigentlich nur, wenn man unwissentlich manuell reinpfuscht (drbdadm oder drbdsetup), also bspw. irgendein Device zum Primary macht, während es auf der anderen Seite bereits Primary ist. Solche Sachen eben.
Ist ganz interessant. Also berauschend finde ich die Werte z.B. für "random reads" nicht, von "random writes" reden wir gar nicht erst. Kannst du den Aufbau noch mal etwas detaillierter für mich erklären? Danke.
MSA1000 oder 1500? Wieviele Platten? Welche Firmware? Welche Distribution soll als Basis dienen? Welche Switches kommen zum Einsatz?
2xDL360G5, SAS-RAID1 lokal, Xeon5140,4GB RAM
1xMSA1000, 6 Platten@146GB(U320), "neu", doppelte Auslegung aller redundanten Systeme (Controller, Netzteil,..etc..)
Die "Images" liegen dann auf dem Storage, XEN wird mit RH EL AS5 auf den Servern laufen, Hot-Standby mittels Heartbeat.
Welche Switches kommen zum Einsatz?
Switche? Du beziehst dich auf FC? Erstmal keiner, da wir beide Server problemlos direkt anbinden können. Sollte irgendwann mehr Storage/Redundanz notwendig werden kommt das dann noch hinzu...
Grüße, Florian
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.