Anforderungen an REDUNDANTEN LinuxServer

[pikolo]

Hallo,

ich suche für unsere Firma mit ca. 15 Clients und ca. 15 Drucker zwei REDUNDANTEN LinuxServer als File- u. Mailserver. FTP, Apache und Mysql sollen auch darauf laufen.
Das wichtigste ist ABER die Stabilität und erst dann die Leistung. Finanziell habe ich bis zum mittleren vier stelligen Bereich freier Hand. Bei Überzeugung sogar mehr, da unser ganzes Geschäft fast über Email läuft. Da es zur Zeit einigermaßen alles läuft, ist es nicht dringend aber schon gewünscht. Also meine Fragen:

1a. welche Hardware sind min. Voraussetzung dafür und notwendig. Was wäre dann aber die Empfehlung um nicht an falsche Ecke zu sparen ?

2. mit welchem Distr. kann ich das zur Zeit (am einfachsten und am besten) realisieren ?

3. Kann ich als bisherige Anwendeungsentwickler auf Ause (nicht Admin) Debian drauf setzen und administrieren od. braucht man mehrjährige Erfahrung in Adminbereich ?

4. Wo sind die obergrenzen bei Debian, was HCL anbetrifft.? z. B. CPU(Xeon, 2 CPU’s, DualCore usw.) Empfehlung ? Abraten ?

5. wenn nicht Debian dann Redhat Enterprise (bisher gar keine Erfahrung damit) od. Suse Enterprise?
Welche ist stabiler?
Welche ist leichter zu administrieren ?

6. sollte ich bei Suse u. Redhat die aktuellste Version kaufen, od. lieber die vorletzte ?

5. Bisher hatten wir alles von Dell gekauft und die bitten schon mal gar kein Debian(nur Red Hat u. Suse). Würde ich mit der Installation von Debian ein Risiko eingehen, was die Garantie anbetrifft. Wie würde es mit Support aussehen? Hat jemand diesbezüglich Erfahrung ?

Danke vorab :)

[marce]

Wenn das Ding wirklich Produtionskritisch ist - Marken-Hardware (z.B. Dell, HP, IBM) mit Marken-BS und Support (z.B. RedHat, Suse, seit 6.06 auch Ubuntu), jeweils in der Enterprise-Version.

Die ensprechende Konfig sollte im Portfolio des jeweiligen Anbieters enthalten sein - einfach mal nachfragen.

Bastellösungen sind in dem Bereich _nicht_ zu empfehlen.

[Simcemilia]

Hallo,

kann mich marce nur anschließen.

Als Hardware Basis HP oder IBM, wobei ich lieber mit HP Hardware arbeite.

Als OS würde ich die Enterprise Versionen von SuSE oder Red Hat nehmen.
Welches man von den beiden dann nimmt ist eigentlich egal.
Man nimmt das mit dem man lieber arbeitet oder mehr Erfahrung hat.

Gruss

Simcemilia

[bla!zilla]

Definieren wir mal "kritisch" und "redundant". Was für ein Verfügbarkeitslevel, bzw. Availability Environment Classification strebst du an? Zur Wahl stehen

Conventional - AEC 0
Highly Reliable - AEC 1
High Availability - AEC 2
Fault Resilient - AEC-3
Fault Tolerant - AEC 4
Disaster Tolerant - AEC 5

Alles über AEC 2 wird richtig teuer. :)

Empfehlung: 99,9% erreichst mit guter Hardware, Support und einem sauberen Setup des Servers. Wenn du zudem Test- und Produktionsumgebung trennst, ist das mit Sicherheit drin. Hardware empfehle ich dir HP, als OS den SLES von Novell.

[pikolo]

@bla!zilla
ich würde sagen AEC 2, da zwei Ziele zu erreichen sind:
1- Emails sollen zu jederzeit senden u. empfangen werden können(also mailserver soll immer verfügbar sein).
2- fileserver soll immer Daten zur Verfügung stellen.

Ich formuliere meine Frage um.
Wie kann ich am günstigsten immer einen Server zur Verfügung stellen, der nicht sonderlich schnell, aber immer erreichbar sein muß.

Kann ich mit Hardlink die wichtigsten Verzeichnisse(Speicherort der Mails und shared Files) permanent auf dem Backup Server spiegeln, um im Notfall mit Backup Server weiter zu arbeiten.

Mir würde vom Dell ein Server inklusive einen teuren Tapdrive(ca. 1600€) und
4 Std. Support angeboten für einen Gesamtpreis für ca. 6T€. Wäre meine Idee
mit Hardlink und zwei günstigere Server nicht besser? Da selbst bei einer Reaktionszeit von 4 Std. und unter Umständen komplette neuinstallation ist ein
Arbeitstag um:(

Wäre ein Cluster aus zwei Nodes eine gute Alternative ? Wie schwer ist die Einrichtung eines Cluster aus zwei Nodes? Muss man Experte sein? Mit welchem Distrib und/od. Prog. ist es zur Zeit möglich.

[marce]

wenn Du es auf eigene Faust lösen willst - schau Dir mal heartbeat und DRBD an.

Ein Cluster aus 2 Nodes ist immer besser als eine Kiste - wobei für die beiden Nodes trotzdem ein 24x7x4-Service gelten sollte - ansonsten, das Tape hat mit HA nichts zu tun - HA hin oder her, ein Backup-Konzept _muss_ trotzdem immer vorhanden sein. HA ersetzt kein Backup.

[bla!zilla]

AEC 2 besagt aber das der Service zur Hauptbetriebszeit nur minimal unterbrochen, bzw. nur innerhalb festgelegter Zeiten unterbrochen werden darf. Um ein Cluster wirst du also nicht herumkommen.

Ich kann es immer nur betonen: Hochverfügbarkeit ist kein Spiel bei dem man spart. Wenn man Hochverfügbarkeit will, dann muss man sie auch bezahlen - immerhin würde mich der Ausfall ja Geld kosten. Es ist auch keine Spiel in dem man ohne Vorkenntnisse etwas machen sollte.

Wenn dir zwei billige Server und DRDB reichen - okay. Ich kenne deine SLAs nicht, aber ich fürchte, so wie du die Situation beschreibst, das du auch nicht wirklich oft mit hochverfügbaren Serversystemen und SLAs zu tun hast. ;)

Wenn du 6000 € für einen Server mit Datensicherung (die muss sein, wie Marce schon sagte ersetzt HA keine Datensicherung) und Support mit 4h Reaktionszeit teuer findest, was stellst du dir dann vor? Was machst du denn wenn du zwei billige Kisten nimmst und in einem Jahr geht an einer was kaputt. Da du aber keinen Support hast und Consumerhardware verwendet hast, gibt es das Ersatzteil nicht mehr. Der Nachfolger der defekten Hardware funktioniert aber nicht (aus welchen Gründen auch immer).... schon rächt sich das sparen an der falschen Stelle auf die wohl grausamste Weise.

[asterixxer]

Ich habe hier zwei DL385 von HP im Einsatz.
Also OS setzte ich SLES 9 von Novell/Suse ein. Auf Server A laeuft Mail auf B File and Print. Das ganze ist gegeinander mit LifeKeeper abgesichert (Cluster Software [d.h. b kann Aufgaben an A uebergeben und umgekehrt]) Diese ist allerdings kostenpflichtig. Vorteil: Der Support ist gleich mit drin und die Leute von SteelEye Support helfen einem auch mal leicht auserhalb vom eigentlichen Cluster Problem.
Man kann sowohl Datenreplikation (spiegeln der Nutzdaten ueber GBit) von der ClusterSW machen lassen, als auch mit einem gemeinsamen Storage arbeiten.

Asterix