Storagespace als ausfallsichere Lösung?

  • Netcup bietet Netzwerkfestplatten an (https://www.netcup.de/vserver/storagespace.php, wodurch ich laut Angabe mit mehreren Servern auf die gleiche Festplatte zugreifen kann. Wenn ich also 2 Server beantrage mit Failover-IP, wobei beide Server auf den selben Storage-Space zugreifen (wo die Daten der Datenbank liegen), dann habe ich dadurch ja auch nichts gewonnen, denn falls wieder folgendes Szenario eintritt, dass Netcup während des Tages alle Server für 30 Minuten vom Netz nehmen muss (wie bei der Spectre-Geschichte), dann wird auch irgendwann der Storagespace vom Netz sein, und die Daten sind erst wieder nicht erreichbar und zwar für beide Server.

    Ein Storagespace hilft also auch nicht dabei, ausfallsicher zu sein. Gibt es vielleicht eine andere Hardware-Möglichkeit bei Netcup, Ausfallsicherheit zu erreichen?

  • Bei geplanter Wartung werden niemals alle Server gleichzeitig heruntergefahren – warum also die Datenbankinhalte auf dem Storage-Space vorhalten anstatt gespiegelt auf den Servern? (Wobei es sich in der Praxis empfiehlt, eine ungerade Anzahl von Cluster-Knoten zu betreiben, um Widersprüche anhand von Mehrheitsentscheidungen aufzulösen – das gilt sowohl für verteilte Dateisysteme als auch für Anwendungen wie Datenbanken.)


    Nachtrag: Im obigen Post wurde nicht erwähnt, um welche Datenbank es sich handelt, aber in der Regel ist es nicht so einfach, mehrere Prozesse auf verschiedenen Rechnern auf dieselben Dateien zugreifen zu lassen…

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Du willst ne Datenbank auf ein Shared Storage schmeissen wo du nix in der Hand hast, vermutlich schön brav mit NFS mountest und der Share sich jeder Zeit verabschieden kann, kuhle Sache!


    Aus Erfahrung sage ich dir gleich, NFS ist für Datenbanken so absolut das schlechteste was man machen kann. Nen NFS share ist schon als Backup Ziel für XtraBackup eine absolute Katastrophe, weil keiner so wirklich sicherstellt, in der gesamten Kette, ob die Daten in erste Linie überhaupt schon geschrieben wurden und wie es um deren Konsitent steht.


    Datenbanken legst du bitte immer auf die lokale Platte völlig frei von den Umständen, wenn du Verfügbarkeit möchtest bau dir nen Master-Slave bzw. nutze bereits in der Software implementierte Funktionen. Das ist um 99% besser als ne Datenbank auf NFS shared zu machen. Da kann es vermutlich auch passieren das Netcup dir irgendwann den Share wegknallt, weil du IOPs verbrätst jenseits von gut und böse.


    Offtopic am Rande:

    Sofern ich mich nicht falsch erinnere hat Netcup ne NetApp im Einsatz das bedeutet das Ding ist 24/7 am laufen. Die Teile haben nicht mal eine Power-Taste und wenn die es mit DataOntap Clustered am laufen haben können die den Stuhl on the fly updaten.

  • @m_ueberall Es handelt sich um PostgreSQL. Hierbei wurde mir in einem anderen Posting schon eine Möglichkeit der DB-Replikation aufgezeigt mit https://repmgr.org/.
    Ich will eigentlich nur, dass meine Services (Apache / Wildfly / PostgreSQL (R/W)) immer erreichbar sind. Wie das zu bewerkstelligen ist, versuche ich mit meinen Beiträgen hier in Erfahrung zu bringen. Es muss also nicht notwendigerweise eine zentrale DB geben. Bisher weiß ich aber noch nicht, welche Lösung letztendlich die für mich die vernünftigste ist, d.h. wie ich die einzelnen Bausteine miteinander verbinden kann, um das genannte Szenario, eine praktisch ausfallsicherere Erreichbarkeit zu gewährleisten.
    Vermutlich wird es anhand meines aktuellen Wissensstandes auf eine Lösung mit einem aktiven und einem Fallback-Server mittels Failover-Switch hinauslaufen, wobei die DB mittels RepMgr synchron gehalten wird. Beide Server haben hierbei eine identische Konfiguration und Installation, wobei bei Nicht-Erreichbarkeit des einen Servers der andere mit der gesyncten Datenbank sofort übernehmen kann. Wäre dieser Ansatz in der Form richtig und praktikabel?


  • Tipp am Rande, versuch bitte deine Thematik in einem Thread zu behandeln. Hier haben wir nun ein Eckstein und im anderen Thread einen anderen. Damit ist es für dich und alle anderen nicht einfach den Überblick zu haben, oder gezielt helfen zu können.

  • Wäre dieser Ansatz in der Form richtig und praktikabel?

    Also wir sind bei 99,9% Verfügbarkeit im Jahresmittel. Das sind 8,7h Ausfallzeit pro Jahr.

    Solltest du eine höhere Verfügbarkeit benötigen, musst du mehr Geld in die Hand nehmen.


    Replikation müsste Multi-Master sein. https://www.2ndquadrant.com/de…postgres-bdr-2ndquadrant/

    Multi-Master ist sehr pfui. Inkonsistenzen sind vorprogrammiert. Oder du machst einen Read-Only Slave. Wer führt den R/W Split durch?

    Wie erreichst du Partitionstolleranz? Wie schützt du dich vor Netzwerkpartitionen?

    Ist die Anwendung Cluster-Aware?

    Was passiert mit Daten, die nicht in der Datenbank liegen?


    Aufwand <=> Nutzen

    Entweder du betreibst eine App die pro Stunde mehrere Tausend Euro Umsatz generiert, dann hostest du aber mit deinen Kenntnissen nicht selber und erst recht nicht bei Netcup, oder aber es ist schlicht nicht sinnvoll.


    https://de.wikipedia.org/wiki/CAP-Theorem

  • H6G Vielleicht hast du recht, dass sich der Aufwand gar nicht lohnt.
    Meine Anwendung besteht aus mehreren Microservices, dazu kommt noch die regelmäßige Wartung des Systems (d.h. oft Reboot). Im besten Fall ist die Anwendung für 3 -5 Minuten nicht erreichbar. Die 3-5 Minuten kommen daher, dass ich vor jedem Update im Server Control Panel immer einen Snapshot erstelle (Herunterfahren, Snapshot ziehen und das Hochkommen aller Services nach dem Start).
    Deshalb habe ich mir eine Lösung vorgestellt, bei der ich mal auf der einen Instanz arbeite, diese aktualisiere und wieder hochfahre, und dann auf der anderen, sodass diese zeitliche Lücke bestmöglich geschlossen wird. Damit kann ich ja fast noch leben, aber Sonderfälle wie eben solche Geschichten mit Spectre, wo Server vielleicht gleich mal 30 min down sind, sind mit irgendwie ein Dorn im Auge. Ich weiß auch nicht ob es Sinn hat, ein Realtime-Backup der DB zu haben. Bisher hatte ich zwar keinen Anwendungsfall, wo das eine Rolle gespielt hätte, aber man weiß ja nicht. Deshalb meine Idee, doch gleich eine redundante Lösung aufzusetzen. Aber vielleicht lohnt sich all der Aufwand wirklich nicht. Ich werde nochmals darüber nachdenken.

  • Im besten Fall ist die Anwendung für 3 -5 Minuten nicht erreichbar.

    Das sollte in der Nacht doch niemanden stören? Die Wartung kannst du doch bequem außerhalb der Rush-Hour platzieren.

    Die 3-5 Minuten kommen daher, dass ich vor jedem Update im Server Control Panel immer einen Snapshot erstelle (Herunterfahren, Snapshot ziehen und das Hochkommen aller Services nach dem Start).

    Das dauert aber keine 3-5 Minuten, das kann auch deutlich länger dauern ;) Aber im Grunde ist das SCP nicht der beste Ansatz dafür. Wenn du Änderungen zurücksetzbar durchführen willst, gibt es auf OS-Ebene meist bessere Lösungen (von einem Betriebssystem Upgrade oder ähnlichem mal abgesehen, aber dsa macht man alle paar Jahre einmal).

    aber Sonderfälle wie eben solche Geschichten mit Spectre, wo Server vielleicht gleich mal 30 min down sind, sind mit irgendwie ein Dorn im Auge

    Dann bist du irgendwo bei 99,95% oder 99,99% Verfügbarkeit im Jahresmittel wenn dir 30min Downtime schon zu viel sind. Du kannst ja mal etwas googlen/recherchieren wie viel Aufwand man für solch eine Verfügbarkeit treiben muss und welches Fachwissen dafür von nöten ist...

  • Ich betreibe einen MariaDB 3-Node Cluster (Master-Master) mit dem Ziel der Ausfallsicherheit. Den Anwendungen ist dies nicht bekannt. Jeglicher Traffic wird stets auf einen Node geroutet, sollte dieser Ausfallen wird ungeschwenkt (FailOver-IP).


    Die "Synchronisation" findet Applikationsseitig statt. Sprich: Jeder Node hat lokal "die Datenbank" gespeichert. Bitte kein rumgefrickel mit irgendwelchen gesharten Mounts... Das geht spätestens schief, wenn man MariaDB aktualisiert (Verschiedene Versionen greifen gleichzeitig auf die Datenquellen zu)


    Während der Spectre-Updates war meine DB bspw. durchgehend erreichbar.

  • Hay,

    Dann bist du irgendwo bei 99,95% oder 99,99% Verfügbarkeit im Jahresmittel wenn dir 30min Downtime schon zu viel sind. Du kannst ja mal etwas googlen/recherchieren wie viel Aufwand man für solch eine Verfügbarkeit treiben muss und welches Fachwissen dafür von nöten ist...

    da kann ich kurz mal aushelfen. Bei einem ehemaligen Arbeitgeber haben wir eine Plattform mit 99,995% betrieben. Zentraler Punkt waren 2 Alteon Loadbalancer (in Hardware) zu je 25.000 Euro. Kann man mittlerweile sicherlich günstiger bauen, aber normalerweise unterhält man sich bei dieser Verfügbarkeit über solche Dimensionen.


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Danke für eure Ratschläge.


    julian-w

    Zitat

    Wenn du Änderungen zurücksetzbar durchführen willst, gibt es auf OS-Ebene meist bessere Lösungen

    welche Lösungen empfiehlst du diesbezüglich, zB Timeshift? (Ich habe mich aber noch nicht näher damit beschäftigt)