hochverfügbarer server

hochverfügbarer server (32 Beiträge, 1013 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

hallo!

bei mir stellt sich derzeit die frage einer installation eines hochverfügbaren servers, sprich cluster gegen ausfall und hotplug support für die hardware (festplatte usw...)

jetzt ist die frage.. welche linux distribution...

fedora, opensuse. redhat, suse enterprise server?

der suse enterprise hat zwar die clusterung integriert aber auch da gibts ja einfach die open source produkte zum nachinstallieren.. wie das mit dem hotplug support der hardware ausschaut weiß ich allerdings nicht..

sollte ich eine redhat oder suse distribution kaufen.. unter anderem wegn den integeriertn features der hochverfügbarkeit bzw wegn den patches oooder...

ich lad mir eine nicht konstenpflichtige distri runter, installier die clustersache nach und wart auf patches 1 tag länger als bei den kostenpflichtigen..

was würdest ihr mir empfehlen?

linux is for networking, apple for working and windows for solitair

aufgabengebiete vom server?

Aktuelles:Biete Externe SCSI HD's

Zitat:
Ubi Pus, ibi evacua ("Wo Eiter ist, dort entleere ihn")
Ich will nicht ins Paradies,
wenn der Weg dorthin so schwierig ist!

verschieden, geht auch nicht nur um 1 server ... mail, radius, datenbanken, usw..

linux is for networking, apple for working and windows for solitair

ich/wir betreiben unsere linux server mit redhat enterprise linux 4 as. die clusterlösung musst du dort allerdings nochmals extra dazukaufen ~600$. weiters wäe der service-guard von hp noch eine möglichkeit, hängt aber von deiner hardware ab. ist es ein metrocluster oder sind die server im gleichen rack etc.? redhat hat einen meiner meinung nach kompetenten support.

open source ist ja gut und recht, aber wenn der hut brennt dann weißt du den support erst richtig zu schätzen

ja beim suse is die clustersache dabei glaub ich... egla...

service-guard von hp sagt mir leider nix... sind aber hp server

die servers sind nicht zwangsweise im gleichen rack, aber werden dann zumindest über standleitung netzwerktechnisch zusammenhängen.

open source ist ja gut und recht, aber wenn der hut brennt dann weißt du den
support erst richtig zu schätzen

weiß ich nicht, hatte ich noch nie, kanns mir daher auch nicht vorstellen wie mir der support helfen kann

linux is for networking, apple for working and windows for solitair

wie ist die datenhaltung bei den servern? haben sie lokale platten oder liegen die platten in einem SAN mit Plattenspeicher? sind alle applikationen die du betreiben willst auch cluster fähig?

hp vertreibt mit ihren servern auch redhat inkl. support. allerdings sind das keine geringen kosten. kommt halt immer darauf an was du willst und brauchst.

der service guard ist für metrocluster-lösungen. switcht diverse applikationspakete usw.

eine frage, was für freeware/open source clusterlösungen hast du dir angesehen, kannst du etwas empfehlen? thx

23.11.2005, 22:02 Uhr - Editiert von narayan_gw, alte Version: hier

nachdem auf den vorhandenen servern suse läuft ist eigentlich redhat nicht wirklich intressant...

sind lokale platten

was ich mir vorstelle.. z.b. der mail server... ein kluster.. verschiedene standorte über standleitung zusammengeschalten... 1. ip unter der der server erreichbar ist.. dahinter beliebig viele rechner die alle den gleichen mailbestand haben, sprich die mails an sich aber auch die userdatenbank (mysql). wenn einer der rechner ausfallt merkts aber kein user..

eine frage, was für freeware/open source clusterlösungen hast du dir
angesehen, kannst du etwas empfehlen? thx

ausprobiert hab ich noch nichts, bin aber über einige websites gestolpert..

linux is for networking, apple for working and windows for solitair

was für einen mailserver willst du einsetzen. läuft die mysql datenbank auf einem eigenen server ja? wie willst du das lösen?

postfix + courier imap
die mysql lauft derzeit am gleichen rechner.. wird sich aber glaub ich so schnell auch nicht ändern

ein failover-cluster ist in dem fall ja nicht ausreichend... da am standby system die mails ja nicht synchronisiert sind so weit ich da informiert bin.. und was das senden und empfangen von mails betrifft würde da ein backup mx mail server ausreichen...

beim webserver würd ein failover absolut ausreichen.. mir gehts speziell ums abrufen der mails

edit: einen ftp server gibts auch noch, da sollten ebenfalls alle daten auf jedem rechner vorliegen.. logischerweise

das ist übrigen so ein open source failover wie ich vorher angesprochen hab (habs wieder gefunden

)
http://www.linux-ha.org/

linux is for networking, apple for working and windows for solitair

23.11.2005, 22:52 Uhr - Editiert von sharky2, alte Version: hier

da am standby system die mails ja nicht synchronisiert sind so weit ich da
informiert bin..

fürs synchronisieren gibts DRBD, wenn Du auf zwei Server synchronisieren willst brauchst Du zB DRBD+.
http://www.linbit.com/de/drbd/drbd-plus/

aber "beliebig" viele Rechner kannst Du damit auch nicht synchron halten!

Heartbeat (linux-ha) übernimmt eigentlich nur das Failover, DRBD das klonen der Daten.

lg
tom2k

Wenn du KnowHow hast und die Chance hast, auf Enterprise-Server-Produkte zu verzichten - verzichte darauf.

Als Jahrelanger SLES-Benutzer kann ich von ausreichend Problemen beim SLES berichten - und ich vermute die RedHat-Schiene ähnlich.

Von der Idee ist es bei SLES so, daß Produkte länger eingefroren werden - und auf einem "stabileren/sichereren" Stand als bei "normalen" Distris sind. Dieses einfrieren ermöglicht dir jetzt den Einsatz von Software, für die du zertifizierte OS darunter brauchst, wenn du den Support nutzen willst - wie zB Oracle.

Wenn du also SW hast, die Enterprise-Produkte darunter voraussetzt - dann ist die erste Entscheidung eh getroffen. Wenn dem nicht so ist - meide die Enterprise-Produkte. So ist es zB heute praktisch unmöglich, aktuelle NSA-Tools/Policies für SELinux unter SLES zu betreiben - einfach weil die Gschichtn von SLES zu alt sind. Wenn du aber alle [auf eigene Faust] austauscht, dann verlierst eh den Support - und dann ist SLES wieder sinnlos geworden.

Vorteil von Enterprise-Produkten: Du hast das durchwassern von Security-Mailing-Lists outgesourced - mit allen Vor- und Nachteilen...

Versteh' mich nicht falsch... SLES oder das Redhat-äquivalent machen in vielen Sachen durchaus sehr viel Sinn. Der Schluß "Enterprise-Computing braucht Enterprise-Distri" ist allerdings grob falsch - außer die eingesetzte SW zwingt dich dazu aus Support- oder Lizenzgründen.

cu
gepeinigter.

Ach ja, wenn es nicht eine Enterprise-Distri werden soll, würde ich die aktuelle SuSE10 ausprobieren. SuSE ist tendenziell ein bißchen buggy aber seeehr aktuell (libs, apps) und hat einige Kernel-Extensions drinnen. Mir persönlich ist es lieber, ein paar Gschichten (meist eh nur Scripts) zu debuggen als öfter alle Libraries auszutauschen (was mir meist weit mehr Streß verursacht und IMHO mehr Zeit kostet).

Ansonsten klingt für mich Gentoo seehr nett. Ich würde zwar nicht alles selbst kompilieren lassen (da ist mir meine Zeit zu teuer/schade), aber überraschenderweise gibt es ausgerechnet für Gentoo scheinbar den besten SELinux-Support... Und gerade im Enterprise-Bereich finde ich SELinux eine wirklich seeehr geniale Variante... Ich kenne kein anderes Betriebssystem, daß nicht einen Großrechner drunter braucht und B-Level-Security anbietet.

der mail server lauft derzeit sowieso auf suse 10 mit postfix, courier imap und mysql... beim ftp server wirds vorerst suse 10, proftp und mysql...

ich sag für mich muss es überhaupt kein enterprise server sein.. mir gehts nur um die möglichkeit der hochverfügbarkeit.. kein einfaches failover da bei den beiden servern die daten ja gespiegelt werden müssn... jetzt hab ich heut in der doku vom SLES nachgeschaut und genau das gefunden was ich brauche.. ein warm standby...

ich hab mir aber überlegt eventuell die daten per rsync zu synchronisieren und einfach ein failover zu benutzen

was allerdings beim SLES noch möglich ist, das austauschen von hardware im betrieb.. sprich ram,festplatte...

ich persönlich würde ja beim suse 10 bleiben aber gerade das warm standbye und der hotplug support sind die gründe warum ich derzeit zu SLES tendiere..

linux is for networking, apple for working and windows for solitair

Da sitzt du IMHO einem Fehler auf.

Der ganze 2.6er-Kernel ist eh hotplug-Fähig. Das geht soweit, daß der Kernel ein hotplugging der CPU ermöglicht (was wirklich Sinn macht. Zwar net physikalisch

, sondern wenn du virtuelle Maschinen betreibst und einer Linux-Partition mal auf die schnelle mehr oder weniger CPU's zuordnen willst).

Hotplug können also alle. Ich nutze das für meine Festplatten (die auf SW-Raid sitzen).

Heartbeat können IMHO auch alle...

Ich möchte dir noch coda als Dateisystem empfehlen...
http://www.coda.cs.cmu.edu/
Ist zwar grundsätzlich für mobile-Computing gedacht, läßt sich aber auch für Server "mißbrauchen" und so im Produktiveinsatz - auf der Seite beschrieben.

rsync rate ich ab... Du bist dann immer out-of-date - und hast ordentlich CPU-Last.

DRBD wiederum habe ich nie probiert. Mich persönlich macht ein Block-Device-spiegeln mißtrauisch... Das kann nur dann sauber funktionieren, wenn der backup-Server das Block-Device nicht gemountet hat... Denn zB reiserfs würde ja empfindlich reagieren, wenn ihm wer "unter dem Hintern" was reinschreiben wollte. IMHO (und wirklich nur IMHO, net Fakt!) kannst du damit echt nur Standby-Systeme ermöglichen... Wenn aber eh beide Server "up and running" sind, wäre es ja ein Verbrechen, nicht beide parallel zu nutzen und Load-Balancong zu fahren.

Durch coda hingegen könnten beide parallel arbeiten...

Wie auch immer, alles von dir geforderte klappt auch ohne SLES (oder äquivalente).

Wie auch immer, alles von dir geforderte klappt auch ohne SLES (oder
äquivalente).

das hab ich eigentlich gehofft

derzeit ist die clusterfähigkeit noch kein muss, ich möchts aber für die zukunft schon miteinplanen

also für die hartbeat sache würde ich jetzt vorerst http://www.linux-ha.org/ einsetzten.

was ich jetzt fürs synchronisieren einsetzten werde muss ich mir noch überlegen..

wie schon gesagt bin ich mit suse 10 zufrieden und muss nicht SLES einsetzn solangs nicht wirklich einen guten grund gibt, aber mal schauen was die geschäftsführung dazu sagt (hat sogar etwas ahnung von sowas

)

linux is for networking, apple for working and windows for solitair

Soweit sogut

Nur deine Sig mußt ändern... FreeBSD is for Networking

Im Rahmen von lartc bin ich nun schon auf NW-Features gestoßen, die es in FreeBSD gibt, aber nicht in Linux

ah ob linux oder freebsd ist nicht mehr sooo wichtig... kernpunkt ist ja dass windows für solitär ist

linux is for networking, apple for working and windows for solitair

hab gestern und heute wieder festgestellt dass ich vom SLES nicht wirklich einen vorteil hab... ja schön heartbeat ist über yast zu konfigurieren... aber die tomcat verzeichnisse vom suse rpm zu finden is schon viel komplizierter als einfach nur das gezippte file runterladen und extrahieren *kopfschüttl*

linux is for networking, apple for working and windows for solitair

Hallo!

DRBD wiederum habe ich nie probiert. Mich persönlich macht ein
Block-Device-spiegeln mißtrauisch... Das kann nur dann sauber funktionieren,
wenn der backup-Server das Block-Device nicht gemountet hat...

Hier hab ich live eine großartige Mißerfolgsgeschichte miterlebt.
Ständig waren am Backup-Server die Filesysteme kaputt, die DB´s runiniert etc.
Und da waren keine "Wappler" am werkeln, sondern echte Insider.
Nach einem Jahr war dann das Projekt gestorben (nach vielen Stunden und Euros)

Glaub ich gerne...

zu coda gibt's ausgezeichnete Erfahrungsberichte, aber ein Block-Device spiegeln - da muß man /echt/ wissen, was man tut...

Man kann sich das Problem ja gerne auch Lokal vorstellen:
Ein DRDB ist ein RAID1 über's Netz, richtig ?

Stell dir ein RAID1 vor, auf das 2 Linuxe gleichzeitig zugriff haben. Einer schreibt in das RAID1, der zweite hat die 2. Festplatte davon im [schreib]-Zugriff.. Das kann nur ins Auge gehen, vermutet der Laie.

Echt, ich habe mal ein /kleines/ Dateisystem geschrieben (Nur Proof-of-Concept für mich selbst unter 2.2), aber du hattest [zumindest damals] keinerlei Möglichkeit in deinem Dateisystemmodul, auf solche Gschichtn (Wenn dir einer unter Arsh das Block-Device modifiziert) Rücksicht zu nehmen...

Wie gesagt, es meine Meinung ist ohne Sachkenntnis hier... Nur DRBD ist für mich etwas, was man ausreichend austesten sollte, /bevor/ man einen Konkreten Realisierungsplan hat. Also nicht unter Zeitdruck, sondern für "Spare Time" zwischen Projekten (so vorhanden). Es klingt nach einer interessanten Technologie mit vielen Einsatzmöglichkeiten - aber nur, wenn man sich aller Konsequenzen und Implikationen bewußt ist..

Stell dir ein RAID1 vor, auf das 2 Linuxe gleichzeitig zugriff haben. Einer
schreibt in das RAID1, der zweite hat die 2. Festplatte davon im
[schreib]-Zugriff.. Das kann nur ins Auge gehen, vermutet der Laie.

Bei DRBD sind NIE beide Blockdevices gleichzeitig veränderbar.

Eine Lösung mit DRBD, Heartbeat und VServer kann zB so aussehen:

Auf Server 1 wird die DRBD-Resource "Primary" gesetzt (somit kannst Du auf Server 2 schonaml nix mehr am DRBD-Device ändern), das journaling Filesystem gemountet, eine IP-Adresse für den Dienst vergeben und der VServer gestartet.

Die Daten werden übers Netz zwischen den beiden DRBD-Devices synchron gehalten.
Fällt Server 1 aus, leitet Heartbeat das Failover ein. Setzt also das DRBD-Device auf Server 2 in den Primary-Status, mountet das Filesystem, vergibt diesselbe IP-Adresse und startet den VServer... der Failoverprozess ist (je nach Konfiguration) in recht kurzer Zeit (<30 Sekunden) abgeschlossen.

Man kann natürlich mehrere DRBD-Devices anlegen und auch Active/Active fahren, indem Server 1 zB den VServer mit Apache beherbergt und Server 2 zB einen VServer-Mailserver laufen läßt. So steht der zweite Server nicht nur dumm rum.

Im Fehlerfall übernimmt einfach der überlebende Server beide Dienste (Web+Mail).

Mit DRBD+ (kostenpflichtig) gibt es auch die Möglichkeit die Daten noch auf einen dritten Server (zB am anderen Ende der Welt) zu spiegeln....

Viele Grüße
tom2k

Da will ich ja hin... Es kann nur einer schreiben (bei coda alle).
Aber wie sieht's nun mit lesen aus ?

Angenommen, SRV1 hat die Blöcke 1,2,3 mit Inhalt A,B,C.
Das ganze ist nun ein RAID über's netz...
Also SRV2 sieht dieselben Blöcke mit demselben Inhalt.

SRV2 sei up-and-running - und will wenigstens Queries read-only beantworten können (load-sharing). Darf SRV2 das nun unter DRDB ? Meine Vermutung ist NEIN.

Begründung:
Angenommen, SRV2 liest oft Block A (zB ein Index-Block der DB). Dann landet BlockA im Page-Cache von SRV2...
SRV1 modifiziere nun BlockA (UPDATE). Bekommt SRV2 das mit ? IMHO vermutlich nicht... Und dann kann's nur scheppern

Wenn der SRV2 die Daten aber net mal read-only mounten darf - dann wird's "unschön"...

Keine Frage, DRDB kann durchaus viel Sinn machen, ich habe nur keinerlei Erfahrungen damit und aus dem Bauch raus [zugegeben eventuell völlig unberechtigt] viele Sorgen damit.

Hallo,

DRDB wurde für HA entwickelt und nicht für Load Balancing. Du darfst das DRBD-Device am zweiten Rechner nichtmal passiv mounten, weil das - wie Du korrekt schreibst - zu Problemen führt.

Eine Art von Load Balancing kannst Du machen, indem Du die verschiedenen Dienste auf die beiden Server aufteilst. Aber Du kannst nicht einen einzigen Dienst "load balancen".

Dieses Bild beschreibt die mögliche Art von Load Balancing recht gut und genau so ist es für meinen Zweck auch ausreichend.


Clients  <--------------+---------------------------+ 
                        |                           | 
              +--------------------+      +--------------------+
              | httpd (on drbd0)   |      | sendmail (on drbd1)|  
              | standby for sendmail      | standby for httpd  |
              +--------------------+      +--------------------+
                     node1                        node2

Quelle: http://www.drbd.org/fileadmin/drbd/doc/0.5.7/uman.html

Und hier noch ein Auszug aus den FAQs:

Can I mount the secondary at least readonly?

      Short answer: No!

      DRBD would not care, but most likely your filesystem will be confused because it will not be aware about changes in the underlying device. This in general means that it cannot work, not with ext2, ext3, reiserFS, JFS or XFS. If you need not just a mirrored, but a shared filesystem, use GFS or OpenGFS for example. But these are much slower, and typically expect write access on all nodes in question.

      If we have more than one node concurrently modifying distributed devices, we have some "interessting" problems to decide which part of the device is up-to-date on which node, and what blocks need to be resynchronized in which direction.

      These are the most important reasons why DRBD does not allow mounting the secondary. Thus, if you want to mount the secondary, set the secondary as the primary first. Both devices mounted at the same time does not work.

      If you need access to the data from both nodes, and and arbitrary number of other clients, consider using HaNFS.

Quelle: http://linux-ha.org/DRBD_2fFAQ#head-ff8f594c0d61552676dd75c5c2818546f737f712

Ja, so dachte ich es mir... Danke für die Ausführungen.
Klarerweise kann man - wie du beschreibst - 2 Dienste wechselweise laufen haben und so ein Balancing durchführen...

Der Nachteil dabei ist aber IMHO, daß selten 2 Dienste wirklich dieselbe Last haben - und daher wohl öfters zB http-node Vollast hätte, während der smtp-Node idled (oder jetzt mit den neuen Mailwürmern halt umgekehrt

Der Nachteil dabei ist aber IMHO, daß selten 2 Dienste wirklich dieselbe Last
haben - und daher wohl öfters zB http-node Vollast hätte, während der
smtp-Node idled (oder jetzt mit den neuen Mailwürmern halt umgekehrt ).

ja, wie gesagt: für mich ist diese Lösung momentan ausreichend. Ich bin aber gerade auf der Suche nach CODA+VServer+Heartbeat Tutorials/Wikis/HowTo's/Erfahrungsberichten und schau mir das gerne an....

Was ich bisher aber gesehen habe, bräuchtest Du ja für ein "echtes" Load Balancing sowieso immer noch einen Zusätzlichen Server, der das Load Balancing regelt... Bei mir gehts momentan eig. lediglich um HA, sodass im Fehlerfall der zweite Server schnell wieder online ist.

Viele Grüße
tom2k

Hi !

Natürlich ist der Loadbalancer ein Extra-Service, das rennen muß - allerdings net sonderlich CPU-Lastig. Typischerweise hast du ja ein Bild wie hier:
http://www.linuxvirtualserver.org/HighAvailability.html

Wobei wir ja stattdessen eine günstige Lösung suchen - und das alles in einem Land, wo ich nicht zuhause bin

Es scheint mir aber logisch, daß der Director (und dessen Backup) natürlich auch [im allerallerkleinsten Fall] dieselben Server sein können, auf denen die eigentlichen Dienste (zB HTTP-Server) laufen... Und natürlich scheint es klar, daß man auch den Storage parallel im Zugriff haben kann...

Das ist zwar weiter weg von Performant (weil jeder alles macht), allerdings näher bei HA (weil eben beide "Up-And-Running" sind. No need to remount, kein Zeitverlust zum DB-Hochfahren (was ja bei großen DB's durchaus mal wirklich lange dauern kann), ...

Auf jeden Fall hast du miese Ratte mir wieder den Mund wässrig gemacht, mir das näher anzusehen - und ich hab' eh keine Zeit. Schäm' Dich !

cu
gepeinigter - der weiterhin gerne zugibt, daß er mit Linux-Cluster leider viel zuwenig Erfahrung hat... Eigentlich gar keine

bei uns ist es halt so - wie du bereits erwähnt hast - das wir zertifizierte software wie SAP und oracle einsetzen, dort kommst du nicht um die enterprise schiene herum. da ansonsten kein support des herstellers gegeben wird....tja

Tja, in so einem Fall ist dir eh die Entscheidung abgenommen - keine Frage. Naja, wenigstens wird der Entscheidungsbaum kleiner

Empfehle zwei mittelgute austestattete Dual-Opteron-64-Server von HP, jeweils VMWare ESX 2.5 mit VirtualSMP und VMotion und einen iSCSI-Storage oder besser SAN von EMC. Da kannst jeden Server jederzeit abdrehen ohne dass du ein System runterfahren musst. Und für die Anforderung für verschiedene Applikationen ideal. Innerhalb des ESX kannst du mehrere VMs erstellen, welche untereinader 'geclustert' sind und diese auf beiden Server verteilt haben. Natürlich auch zwei USV's und redundante Netzwerk-Switches.

hach das klingt schön

Wie viel Performance kostet der ESX Server denn die Maschine? wie viel von der Leistung wird ungefähr durchgereicht? ein wenig spüren wird man das sicher, nicht?

würde mich interessieren, da ich bald beginne auf unsereren testservern den esx auch einsetzen will.

thx!

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung