DRBD für HA Server in Small Office-Fragen

Hintergrund: Wir benötigen einen HA-Server in einer kleinen Büroumgebung und suchen nach DRBD, um ihn bereitzustellen. Wir haben nur ungefähr 100 GB, die auf dem HA-Server sein müssen, und die Serverlast wird extrem niedrig sein. Die Daten werden wahrscheinlich um 10 bis 25% pro Jahr steigen, wenn wir ältere Bürodaten archivieren, und um 50 bis 75% pro Jahr, wenn wir dies nicht tun.

Der Punkt ist, dass wir eine Mischung aus Consumer- und gebrauchter Enterprise-Hardware verwenden, was ein Problem sein wird, wenn wir es nicht präventiv planen. und vorgefertigte Qualitätsserver fallen aus, sodass redundante Server der richtige Weg zu sein scheinen.

Der Plan: Wir denken, es wäre gut, (2) die besten gebrauchten Server zu finden und zu synchronisieren. Wir brauchen einfach SATA / SAS-fähige Server und Speicherplatz für so viele Laufwerke, wie für den Preis verfügbar sind. Diese Server scheinen für 100 bis 200 US-Dollar (+ einige Teile und zusätzliche Laufwerke) erhältlich zu sein, wenn Sie einen Deal abschließen.

Dies würde theoretisch bedeuten, dass ein Server ausfallen könnte, und wenn wir Tage brauchen würden, um ihn zu erreichen, würden die Dinge immer noch brummen, bis unsere IT-Abteilung (ich) ihn erreichen könnte, solange wir keinen weiteren zufälligen Ausfall hatten. Wir würden Debian als Betriebssystem verwenden.

Einige Fragen

1. (A) Wie geht DRBD mit Laufwerks- oder Controllerfehlern um? Das heißt, dies zeigt DRBD vor dem Speichertreiber. Was passiert also, wenn der Controller ausfällt und verschmutzte Daten schreibt oder das Laufwerk ausfällt, aber nicht sofort abstürzt? Werden die Daten auf den anderen Server gespiegelt oder nicht und besteht in solchen Fällen das Risiko einer Datenbeschädigung zwischen den Servern?

2. (B) Was sind die Fehlerpunkte für DRBD? Das heißt, theoretisch gibt es NIEMALS Probleme, solange ein Server in Betrieb ist. Wir wissen jedoch, dass es Probleme gibt. Was sind also die Fehlermodi bei der Verwendung von DRBD, da die meisten davon theoretisch Software sein sollten?

3. Wenn wir dafür zwei Server haben, wäre es sinnvoll, VMs auf jedem mit MYSQL und Apache für die Datenbank- und Webserverreplikation auszuführen? (Ich gehe davon aus)

4. Ist DRBD zuverlässig genug? Wenn nicht, ist die Unzuverlässigkeit auf bestimmte Aufgaben beschränkt oder eher zufällig. Die Suche ergab Leute mit verschiedenen Problemen, aber dies ist das Internet mit scheinbar mehr schlechten als guten Informationen.

5. Wenn Daten über LAN synchronisiert werden, verwendet DRBD die doppelte Bandbreite? Das heißt, sollten wir NICS verdoppeln und Link-Aggregation und Trunking durchführen? Dann setzen Sie sie vielleicht auf separate Router in separaten Stromkreisen und USVs in separaten Räumen, und jetzt haben Sie wirklich Redundanz!

6. Ist das für ein Büro in Bezug auf die Serververwaltung zu verrückt? Gibt es eine einfachere REALTIME-Alternative (DRBD scheint theoretisch einfach zu sein).

Wir haben bereits einen Server. Es scheint mir also, dass ein zweiter USED-Server mit einem dedizierten Laufwerk für DRBD mit etwas Smart Shopping leicht für etwa 150 bis 250 US-Dollar erhältlich ist. Fügen Sie einen zweiten Router, mehr Laufwerke, mehr NICs (Gebraucht) und (2) USVs hinzu und sprechen Sie von 1.000 USD +/-. Das ist relativ günstig! Und ich hoffe, dies würde uns hauptsächlich Zeit während eines Serverfehlers verschaffen. Laufwerksausfälle scheinen heutzutage mit RAID einfacher zu handhaben zu sein. Es sind andere Hardwarefehler wie Controller, Speicher oder Netzteile, die möglicherweise Ausfallzeiten zur Diagnose und Behebung erfordern, die das Problem darstellen.

Redundante Server bedeuten für uns, dass gebrauchte Hardware mit mehr Betriebszeit und mehr Flexibilität rentabler wird, um Dinge zu reparieren, wenn mein Zeitplan dies zulässt, anstatt alles anhalten zu müssen, um den Server zu reparieren.

Hoffentlich habe ich nicht vermisst, dass diese Fragen leicht durchsuchbare Antworten haben. Ich habe schnell gesucht und nicht gefunden, wonach ich gesucht habe.

Zunächst müssen Sie definieren, was Sie wirklich mit "HA" meinen. Wovor schützen Sie sich, wie hoch sind die Kosten eines Ausfalls vom Typ X und der Dauer Y? Wie wird sich dies auf Ihre Organisation auswirken? Was ist Ihre Rolle in dieser Organisation überhaupt und was ist Ihre Zeit wert? Wie viel Zeit können Sie dafür aufwenden? Danach müssen Sie entscheiden, ob diese Anforderungen diese Art von Lösung ermöglichen oder ob Sie etwas anderes benötigen.

Zweitens: In meiner Welt passen die Sätze "Ich brauche HA" und "Ich werde beschissene gebrauchte Server für 200 $ kaufen" möglicherweise nicht zusammen (tatsächlich kaufe ich gebrauchten Mist und professionellen Gebrauch jeglicher Art nicht). überhaupt nicht zusammenpassen).

Wie auch immer, Ihre Fragen:

1. Wenn Sie völlig neue Daten in das DRBD-Blockgerät schreiben, werden diese korrekt auf den nicht defekten Controller geschrieben. Es ist eine vollständig transparente Ebene vor den eigentlichen Festplatten, genau wie ein Software-RAID oder LVM. Wenn Sie jedoch aufgrund defekter Controller oder Lesefehlern von der Festplatte eine Datenbeschädigung auf dem Primärknoten haben, kann dies leicht auf den Sekundärknoten übertragen werden, da Schreibvorgänge häufig Lese-, Änderungs- und Schreibzyklen sind, und in diesem Fall ein Block von Beschädigte Daten werden auf dem Primärknoten gelesen und eine Schreiboperation für diesen Block wird an beide Knoten gesendet. Dies bringt den wichtigsten Punkt bei der Verwendung von DRBD zur Sprache: Wie ein RAID ist es in keiner Weise ein Ersatz für ein gutes und zuverlässiges Backup.

2. Ich verstehe nicht, was du hier meinst.

3. Wenn die Verwendung von VMs in einem Einzelknoten-Setup nützlich ist, erfolgt dies auch im Zwei-Knoten-Setup, und Sie haben den Vorteil einer möglichen Live-Migration, wenn dies richtig durchgeführt wird.

4. Nach meiner Erfahrung ja. Sie sollten es jedoch gründlich in Ihrer Umgebung testen und viel Zeit damit verbringen, die verschiedenen Fehlerzustände zu simulieren, die das System erfahren und lernen und dokumentieren kann, wie sie behoben werden können. DRBD ist zwar zuverlässig, aber nicht selbstheilend und erfordert ein gutes Verständnis der Situation, um sich von einem Fehlerzustand zu erholen.

5. Sie möchten wirklich eine dedizierte Verbindung zwischen den Knoten. In einem Zwei-Knoten-Setup kann dies eine Punkt-zu-Punkt-Verbindung ohne Switch oder ähnliches sein. Alles andere mag technisch möglich sein, ist aber nur Unsinn. Abhängig von Ihrem Nutzungsmuster kann die Verwendung von Trunking oder schnelleren Netzwerkkarten (z. B. 10G-Ethernet oder Infiniband) für diese dedizierte Verbindung von Vorteil sein. Wenn jedoch die meisten / alle zu lesenden oder zu schreibenden Daten von der LAN-Schnittstelle stammen, hilft dies nicht weiter Sie sind sowieso durch das LAN eingeschränkt.

6. Dies kommt auf meinen ersten Absatz zurück: Was erwarten Sie davon und was halten Sie von HA? Für einen erfahrenen Systemadministrator kann dies eine kostengünstige und zuverlässige Möglichkeit sein, sich vor einer Reihe von Fehlern zu schützen, erfordert jedoch ein grundlegendes Verständnis dafür, wie die Teile zusammenpassen. Viele kleine Geschäfte ohne eine so erfahrene Vollzeit-SA sind mit hochwertiger Hardware und einem guten Supportvertrag besser dran.

Schließlich: Versuchen Sie nicht, eine HA-Lösung rückwirkend auf Ihre aktuelle Hardware anzupassen. Wie ich schrieb, brauchen Sie die Zeit, um mit dem Setup und seinen Fehlerbedingungen zu experimentieren. Dies erfordert viel Ausfallzeit und kann auf Ihrer Produktionshardware nicht sinnvoll durchgeführt werden.