Fragen zum Single Point of Failure für kleine Operationen

1. Wenn Sie sich keinen Cluster oder Ersatzserver leisten können oder nicht benötigen, der im Falle eines Ausfalls darauf wartet, online zu gehen, können Sie die von einem bulligen Server bereitgestellten Dienste möglicherweise auf zwei weniger bullige Server aufteilen. Wenn also Server A ausfällt, verlieren Clients möglicherweise den Zugriff auf beispielsweise E-Mail, und wenn Server B ausfällt, verlieren sie möglicherweise den Zugriff auf das ERP-System .

   Auf den ersten Blick scheint dies zuverlässiger zu sein, erhöht es nicht einfach die Wahrscheinlichkeit eines Hardwarefehlers? Ein Fehler wird sich also nicht so stark auf die Produktivität auswirken, aber jetzt bereiten Sie sich auf doppelt so viele Fehler vor.

   Wenn ich "weniger bullig" sage, meine ich wirklich eine niedrigere Komponentenspezifikation, keine geringere Qualität. Eine Maschinenspezifikation für die Visualisierung im Vergleich zu zwei Servern für jeweils weniger Last.

2. Oft wird ein SAN empfohlen, damit Sie entweder Clustering oder Migration verwenden können, um die Dienste aufrechtzuerhalten. Aber was ist mit dem SAN selbst? Wenn ich Geld dafür investieren würde, wo ein Fehler auftreten wird, dann nicht für die grundlegende Serverhardware, sondern für die Speicherung. Wenn Sie kein redundantes SAN haben, geben mir diese redundanten Server kein gutes Gefühl des Vertrauens. Für einen kleinen Betrieb wäre es für mich sinnvoller, in Server mit redundanten Komponenten und lokalen Laufwerken zu investieren. Ich sehe einen Vorteil in größeren Betrieben, in denen der Preis und die Flexibilität eines SAN kostengünstig sind. Aber für kleinere Geschäfte sehe ich das Argument nicht, zumindest nicht für Fehlertoleranz.

Dies alles läuft auf das Risikomanagement hinaus. Durch eine ordnungsgemäße Kosten- / Risikoanalyse Ihrer IT-Systeme können Sie herausfinden, wo Sie das Geld ausgeben müssen und mit welchen Risiken Sie leben können oder müssen. Mit allem sind Kosten verbunden ... dazu gehören HA und Ausfallzeiten.

Ich arbeite an einem kleinen Ort, um diesen Kampf zu verstehen, und der IT-Freak in mir möchte nirgendwo einzelne Fehlerquellen, aber die Kosten dafür auf jeder Ebene sind keine realistische Option. Aber hier sind ein paar Dinge, die ich ohne ein großes Budget tun konnte. Dies bedeutet jedoch nicht immer, dass der einzelne Fehlerpunkt entfernt wird.

Network Edge : Wir haben 2 Internetverbindungen, ein T1- und ein Comcast-Geschäft. Planen Sie die Umstellung unserer Firewall auf zwei alte Computer, auf denen pfSense mit CARP for HA ausgeführt wird.

Netzwerk : Durch das Abrufen einiger verwalteter Switches für den Netzwerkkern und die Verwendung von Bonding zum Aufteilen der kritischen Server auf die beiden Switches wird verhindert, dass durch einen Switch-Fehler der gesamte Datenschrank belegt wird.

Server : Alle Server verfügen über RAID und redundante Netzteile.

Sicherungsserver : Ich habe ein älteres System, das nicht so leistungsfähig ist wie der Hauptdateiserver, aber einige große SATA-Laufwerke in raid5 enthält stündliche Snapshots des Hauptdateiservers. Ich habe Skripte eingerichtet, um die Rollen zu wechseln und der primäre Dateiserver zu sein, falls dieser ausfällt.

Offsite-Sicherungsserver : Ähnlich wie bei der Onsite-Sicherung führen wir nächtliche Sicherungen auf einem Server über einen VPN-Tunnel zu einem der Eigentümerhäuser durch.

Virtuelle Maschinen : Ich habe zwei physische Server, auf denen mithilfe von Xen eine Reihe von Diensten in virtuellen Maschinen ausgeführt werden. Diese werden von einer NFS-Freigabe auf dem Hauptdateiserver ausgeführt, und ich kann bei Bedarf eine Live-Migration zwischen den physischen Servern durchführen.

Ich denke, dies ist eine Frage mit vielen Antworten, aber ich würde in vielen kleineren Läden zustimmen, dass die Lösung mit mehreren Servern funktioniert, und wie Sie sagen, läuft zumindest etwas weiter, wenn ein Fehler auftritt. Aber es kommt darauf an, was fehlschlägt.

Es ist sehr schwer, alle Basen abzudecken, aber redundante Netzteile, gute Stromqualität und gute Backups können helfen.

Wir haben Backup Exec System Recovery für einige kritische Systeme verwendet. Nicht so sehr für die tägliche Sicherung, sondern als Wiederherstellungstool. Falls verfügbar, können wir auf anderer Hardware wiederherstellen und das Backup-Image mithilfe der Software in eine virtuelle Maschine konvertieren. Wenn der Server ausfällt und wir auf Hardwarereparaturen warten müssen, können wir eine VM auf einem anderen Server oder einer anderen Workstation starten und humpeln. Nicht perfekt, aber es kann schnell einsatzbereit sein.

In Bezug auf SANs: Fast alles, was Sie verwenden, ist redundant. Selbst wenn es sich um ein einzelnes Gehäuse handelt, befinden sich im Inneren zwei Netzteile, zwei Anschlüsse und zwei „Köpfe“, die jeweils mit Verbindungen zu allen Festplatten verbunden sind. Selbst etwas so Einfaches wie ein von Dell verkaufter MD3000 bietet all diese Funktionen. SANs sind als Kern Ihrer Boxen konzipiert, sodass sie nahezu jeden zufälligen Hardwarefehler überstehen.

Abgesehen davon haben Sie den Punkt, dass Redundanz nicht immer die beste Option ist. INSBESONDERE, wenn es die Komplexität erhöht. (und es wird) Eine bessere Frage ist ... "Wie viel wird das Unternehmen Ausfallzeiten akzeptieren". Wenn der Verlust Ihres Mailservers für ein oder zwei Tage keine große Sache ist, sollten Sie sich wahrscheinlich nicht mit zwei davon beschäftigen. Aber wenn ein Webserver-Ausfall jede Minute echtes Geld verliert, sollten Sie vielleicht die Zeit damit verbringen, einen geeigneten Cluster dafür zu erstellen.

Je mehr Server Sie haben, desto größer ist die Wahrscheinlichkeit, dass etwas kaputt geht. Dies ist eine Sichtweise. Eine andere ist, wenn man bricht, sind Sie zu 100% auf dem Knarren, auch genau wie Sie sagen.

Der häufigste Hardwarefehler sind HDs, wie Sie oben gesagt haben. Unabhängig davon, wie stark Sie Vorgänge aufteilen möchten, müssen Sie Ihren Speicher RAID-fähig machen.

Ich würde für ein paar Server (natürlich RAIDed) statt für einen massiven Server stimmen, sowohl für die Betriebsstabilität als auch für die Leistung. Weniger Software stößt auf die einzelnen Ressourcen, weniger Unordnung, mehr Festplatten zum Lesen / Schreiben usw.

Ich würde mich persönlich für mehrere Server entscheiden. Ich denke nicht, dass ein Geräteausfall in diesem Szenario wahrscheinlicher ist. Ja, Sie haben mehr Geräte, die ausfallen könnten, aber die Wahrscheinlichkeit, dass eine bestimmte Einheit ausfällt, sollte konstant sein.

Wenn ich mehrere Server in einer nicht redundanten / nicht HA-Konfiguration habe, kann ich im Falle eines Fehlers einen Teil der Arbeit auf einen anderen Server verlagern. Angenommen, mein Druckserver fällt aus. Wenn ich dem Dateiserver einige Drucker zuordnen kann, während ich den Druckserver repariere, werden die Auswirkungen auf den Betrieb verringert. Und dort ist es wirklich wichtig. Wir neigen oft dazu, über Hardware-Redundanz zu sprechen, aber die Hardware ist nur ein Werkzeug für die Kontinuität des Betriebs.

Ich arbeite in einem kleinen Geschäft (Ein-Mann-IT-Abteilung) und würde unter keinen Umständen meine mehreren Server gegen einen einzigen austauschen. Wenn einer der Server ausfällt, habe ich die Möglichkeit, die jetzt fehlenden Dienste entweder einem anderen Computer hinzuzufügen oder sie einfach auf einem Ersatz-PC einzurichten. Wir können für die meisten Dinge mit einem Ausfall von ein oder zwei Stunden leben, aber wir können nicht mit einem vollständigen Ausfall aller Systeme leben. Obwohl ich jeden unserer Server zumindest vorübergehend durch einen PC ersetzen kann, habe ich nichts, was annähernd leistungsfähig genug ist, um alle Server gleichzeitig zu ersetzen, oder kann es leicht beschaffen .

In Ihrem ursprünglichen Beitrag wird die Hypothese aufgestellt, dass Sie sich keinen Cluster leisten können, Sie jedoch Lösungen mit zwei Servern in Betracht ziehen (ohne Backups). Das würde bedeuten, dass Sie höchstwahrscheinlich drei Server zur Hand haben, genug, um einen Cluster zu starten.

Es gibt Zwischenlösungen, die SPoF vermeiden können und dennoch für kleine und mittlere Unternehmen geeignet sind: Knoten-zu-Knoten-Replikation ohne SAN-Speicher.

Dies wird zum Beispiel von Proxmox unterstützt (aber ich denke, es wird auch von XCP-ng / XenServer und wahrscheinlich von ESXi unterstützt).

Betrachten wir ein 3-Knoten-Setup. Alle mit RAID, redundantem Netzteil und redundantem Netzwerk.

• Knoten A und B haben eine kräftige CPU und viel RAM.
• Knoten C ist in Bezug auf CPU / RAM bescheidener, verfügt jedoch über viel Speicherplatz und wird verwendet, um das Quorum für den Hochverfügbarkeits-Watchdog und Host-Backups bereitzustellen.

Dann zwei Möglichkeiten:

1. Alle VMs werden normalerweise auf Knoten A ausgeführt und auf Knoten B repliziert (was anständige CPU-Sepcs erfordert).
2. VMs werden zwischen Knoten A und B aufgeteilt und teilweise von Knoten A zu Knoten B und von Knoten B zu Knoten A repliziert.

Diese Art der Einrichtung kann einen Netzwerkfehler, einen vollständigen und schwerwiegenden Knotenfehler (einer der drei) mit einer Ausfallzeit von etwa 1 Minute tolerieren (ungefähr die Zeit, die eine VM zum Starten benötigt). Der Nachteil ist der Datenverlust seit der letzten Replikation (der je nach Einstellungen und Hardwareleistung nur 1 Minute und einige Stunden betragen kann).

Bei der zweiten Option (VM wird normalerweise zwischen Knoten A und B aufgeteilt) müssen Sie priorisieren, welche VM wieder online geschaltet werden darf. Da Ihre VM-Last normalerweise auf zwei Server aufgeteilt ist, kann die Ausführung aller auf einem einzelnen Knoten den RAM des Knotens erschöpfen oder die CPU überlasten.

"Während dies auf den ersten Blick zuverlässiger zu sein scheint, erhöht es nicht einfach die Wahrscheinlichkeit eines Hardwarefehlers?"

• Vom Standpunkt der Hardware aus sehe ich nicht, wie dies die Ausfallwahrscheinlichkeit praktisch erhöht. Hier gibt es viel zu viele Variablen, und ich habe die Wahrscheinlichkeit nie untersucht, aber um es zu vereinfachen: Nehmen wir an, Dell macht 1 fehlerhaften Server pro 100.000, die sie machen. Ihre Chancen haben sich von 1 zu 100.000 auf 2 zu 100.000 (oder 1 zu 50.000) geändert. Also ja, die doppelte Chance, aber aufgrund der Größenordnung sind die Chancen praktisch nicht so unterschiedlich.
• Ich denke, Perspektive ist hier der Schlüssel. "Sie bereiten sich auf doppelt so viele Fehler vor." Vielleicht aus Ihrer Sicht, aber in beiden von Ihnen angegebenen Szenarien wird E-Mail auf einem Server und ERP auf einem Server ausgeführt. Aus der Sicht von E-Mail oder ERP (worum es dem Unternehmen geht) ist es also wirklich dasselbe. Es sei denn, sie werden einsam oder mögen ihren Raum ;-)
• Ich denke, Sie sollten es auch vom Standpunkt der Menschen aus betrachten. Ich denke, ein Fehler aufgrund von Fehlern ist wahrscheinlich wahrscheinlicher, und auf diese Weise würde wahrscheinlich immer nur ein Server gleichzeitig vermasselt. Es macht es auch einfacher, Probleme mit Dingen wie Last zu identifizieren. Wenn sowohl E-Mail als auch eine Website auf einem Server ausgeführt werden, haben Sie zusätzliche Zeit, um herauszufinden, wo das Problem liegt.

Es ist nie so einfach, dass große, bullige Server besser oder schlechter gemacht werden können. Sie haben möglicherweise Teile von höherer Qualität, erzeugen aber möglicherweise mehr Wärme und werden nicht richtig gekühlt. Ein bulliger Server hat mehr RAM, mehr CPUs usw. Am Ende haben Sie in beiden Szenarien vielleicht genauso viele CPUs, sodass ein Server möglicherweise nicht die richtige Einheit ist, über die Sie nachdenken sollten.

Aufgrund der Komplexität der Chancen gewinnt meiner Meinung nach alles, was am kostengünstigsten ist. Wenn Sie für Lizenzen bezahlen müssen, ist 1 großer Server je nach Lizenzstruktur möglicherweise billiger als einige kleinere Server.

Mein Standardansatz besteht darin, eine zentralisierte Infrastruktur zu vermeiden. Dies bedeutet beispielsweise kein SAN , kein Load Balancer . Sie können einen solchen zentralisierten Ansatz auch als "monolithisch" bezeichnen.

Als Softwarearchitekt arbeite ich mit der Infrastruktur des Kunden. Das kann bedeuten, dass Sie ein eigenes privates Rechenzentrum oder AWS verwenden. Daher habe ich normalerweise keine Kontrolle darüber, ob sie ein SAN verwenden oder nicht. Da meine Software normalerweise mehrere Kunden umfasst, erstelle ich sie so, als würde sie isoliert auf einzelnen Computern in einem Netzwerk ausgeführt.

Das E-Mail-Beispiel

E-Mail ist seltsam, weil es ein Legacy-System ist (das funktioniert). Wenn E-Mail heute erfunden würde, würde sie wahrscheinlich RESTFul-APIs auf Webservern verwenden, und die Daten würden sich in einer Datenbank befinden, die mit normalen Tools (Transaktionsreplikation, inkrementelle Sicherungen) repliziert werden könnte.

Die Softwarearchitekturlösung besteht darin, dass eine Webanwendung eine Verbindung zu einem aus einer Liste verfügbarer Knoten herstellt (zufällig). Wenn dies nicht verfügbar ist, wird versucht, eine Verbindung zu einem anderen Knoten herzustellen (zufällig). Ein Client wird möglicherweise von einem Server geworfen, wenn er zu beschäftigt ist. Hier ist kein Load Balancer erforderlich, um eine Verbindung zu einer Webfarm herzustellen. Für eine hohe Verfügbarkeit ist kein SAN erforderlich. Es ist auch möglich, die Datenbank nach Abteilungen oder Regionen zu teilen.

Ware bedeutet ...

Anstatt über teure 1 oder 2 Server und ein SAN mit internen Redundanzmaßnahmen zu verfügen, können Sie mehrere Standardmaschinen mit geringem Stromverbrauch und geringen Kosten verwenden.

• Einfachheit - Redundanz ergibt sich ausschließlich aus der Anzahl der Geräte. Sie können Ihre Redundanz leicht anhand der Anzahl der Maschinen überprüfen. Und Sie schätzen genauer, dass sie eine höhere Ausfallwahrscheinlichkeit haben, und bereiten sich darauf vor.

• Redundanzprozentsatz - Wenn Sie 2 Server haben und einer ausfällt, haben Sie noch 1 (50%). Wenn Sie 10 Commodity-Server haben und einer ausfällt, sind noch 9 übrig (90%)

• Inventar - Ein Warengerät ist in jedem nahe gelegenen Geschäft zu einem günstigen Preis erhältlich.

• Kompatibilität - Mit Glasfaserkanälen und allen Arten von Standards für Festplattenvolumenformate, Standardgeräte und Softwarearchitektur sind Sie nicht an ein einzelnes Gerätemodell oder eine Marke gebunden.

• Leistung - Bei 2 Geräten im SAN müssen sie sich im selben Raum befinden. Mit dem Commodity-Machine-Ansatz können Sie bei 5 Büros 2 in jedem Büro haben, mit VPN-WAN-Redundanz zwischen den Büros. Dies bedeutet, dass sich Software und Kommunikation mit einer Zugriffszeit von <1 ms im LAN befinden.

• Sicherheit - Aufbauend auf der hohen Redundanzstufe können Sie Knoten problemlos als regulären Standardprozess neu erstellen. Möchten Sie einen monolithischen 2-Server-Cluster neu erstellen? Holen Sie das Handbuch heraus. Indem Sie Maschinen häufig (mit Automatisierung) neu erstellen, halten Sie die Software auf dem neuesten Stand und verhindern, dass Hacker oder Viren in Ihrem Netzwerk Fuß fassen.

Hinweis: Sie benötigen weiterhin Redundanz mit mehreren Switches und Gateway-Routern