Architektur für hohe Verfügbarkeit

Ich habe dieses Szenario:

Sie haben eine Fabrik-processlinie, die rund um die Uhr läuft. Ausfallzeiten sind extrem teuer. Die Software, die alle verschiedenen Teile steuert, muss eine gemeinsame Form des databasespeichers verwenden. Der Hauptgrund dafür ist zu wissen, in welchem ​​Zustand sich die Fabrik befindet. Zum Beispiel können einige Produkte gemischt werden, wenn der gleiche Ausrüstungssatz und andere DEFINITIV nicht verwendet werden.

Anforderungen:

  • Ich möchte, dass die Software erkennt, dass ein Fehler in einem Teil der Anlage dazu führen muss, dass die Maschine mehr als 1 km entfernt wird. So stopfen data in der SPS ist keine Option.
  • Updates und Upgrades auf die Fabrikumgebung sind häufig
  • Last (in Computerbegriffen) wird wirklich niedrig sein.

Die Systeme bearbeiten einige Hundert Aufgaben pro Tag, für die Berechnungen / Überprüfungen durchgeführt werden, gefolgt von statementen, die für die Fabrikmaschinen gesendet werden. Systeme werden die meiste time langweilig sein. Wichtigste Voraussetzung ist, dass das zentrale Computersystem korrekt und immer funktionsfähig ist.

Ich dachte daran, eine dynamo-basierte database (Riak oder Cassandra) zu verwenden, wo data auf mehrere Maschinen geschrieben werden, wobei jede Maschine die gesamte database hat

Wenn ein System ausfällt, wird es unbemerkt untergehen. Eine traditionelle SQL-database kann beim Aktualisieren von Tabellen ein größeres Problem darstellen, wenn Tabellen geändert werden und dieser Master-Slave schwerer zu konfigurieren ist.

Was wäre deine Lösung?

Netzwerk wurde überflüssig gemacht und die meisten anderen Single Points of Failure zu. Das databasesystem ist kritisch, da die Ausfallzeit der db Ausfallzeiten für die gesamte Anlage und nicht nur für eine der Maschinen bedeutet, die akzeptabel ist.

  • Wie man das Problem des gemeinsamen Zustandes triggers.
  • Komplexität in der database wird kein Problem sein. Ich werde mehr wie ein einfacher Schlüsselwertspeicher sein, um die aktuellsten und korrekten data zu erhalten.

Solutions Collecting From Web of "Architektur für hohe Verfügbarkeit"

Ich denke nicht, dass dies eine SQL / Nosql-Frage ist. Alle Postgres, MySQL und MS SQL server verfügen über eine Art Cluster- oder Hot-Standby-Option.

configuration ist eine einmalige Sache, aber jede NoSQL-Option wird Ihnen Kopf-bis-Fuß-Probleme bereiten, wenn Sie versuchen, etwas grundlegend Relationales auf einer Plattform zu tun, die relational für den Zweck der Ausführung von Dingen aufgegeben hat wie Amazon oder Facebook. Die configuration ist einmalig, die Codierung ist für immer.

Also würde ich sagen, bleib bei einer bewährten Lösung und bringe diese heiße Replikation in Gang.

Dies bietet auch eine Lösung für Upgrades. Die typische Abfolge besteht darin, auf die Bereitschaftsdatenbank "Fail-Over" durchzuführen, den Master zu aktualisieren, zum Master zurückzuschalten, die Standby-Version zu aktualisieren und fortzufahren. Mit Details zur Situation natürlich.

Verwenden Sie ein etabliertes RDBMS, das solche Dinge nativ unterstützt

Wollen Sie wirklich ein rund um die Uhr einsatzbereites System auf etwas ausführen, das zu jedem timepunkt konsistent sein kann?

Sie müssen einzelne Fehlerquellen vermeiden.

Alle wichtigen Akteure in unserer dbms-Welt bieten mindestens eine Möglichkeit, die database selbst nicht zu einem einzigen Fehlerpunkt zu machen. Ich frage mich vielleicht, ob sie Änderungen schnell genug für Ihre Fertigungsprozesse weitergeben können. (Oder ist die dataaktualisierung nicht wirklich ein Problem? Kann ich nicht wirklich aus Ihrer Frage erfahren.) Meine db-Arbeit in der Fertigung beschränkt sich auf das Auto und die chemische Industrie. Mikrosekunden waren ihnen egal.

Aber das dbms ist nicht das einzige, was scheitern kann. "Immer arbeiten" bedeutet, dass die Kunden auch immer arbeiten müssen. Client-Hardware, Verbindungen zum Netzwerk, Netzwerk- und Netzwerkserver selbst haben wahrscheinlich einzelne Fehlerquellen. Fehlertolerante server verfügen über mehrere Netzteile, mehrere NICs usw.

"Immer zu arbeiten" ist sehr teuer. Ich habe das Gefühl, dass die database nicht das größte Problem für Ihr Unternehmen sein wird.