Beiträge von Bevor

    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.

    @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?


    Zitat

    Also brauchst Du eine Lösung wie die IP im Fehlerfall auf den anderen Server gerouted wird

    Ja schon, aber das erledigt doch das Netcup-Zusatzpaket "Failover/IP", oder? Ich kann nämlich nur eine Zusatz-IP buchen (dann müsste ich mich um den Failover-Switch selbst kümmern), oder ich kann eine Failover/IP buchen, wodurch mir diese Arbeit abgenommen wird, richtig?
    (https://www.netcup.de/vserver/root-server-erweiterungen.php)

    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?

    Ok, ich habe jetzt aber noch nicht verstanden, ob ich für die Netcup-Failover-IP überhaupt irgendwelche Serverkonfigurationen vornehmen muss. Mit anderen Worten, ich kann auf Pacemaker und Heartbeat (oder ähnliche Konzepte) verzichten, wenn ich einfach eine Netcup-Failover-IP beantrage (und dort vermutlich über das CCP? beide Server eintrage), korrekt?

    Mein Synchronisationsproblem ist dadurch natürlich nicht gelöst, aber hierzu stelle ich in einem anderen Betrag eine Folgefrage.

    Hallo,
    ich habe versucht mir zu überlegen, wie ich ein ausfallsicheres Server-Setup (Ubuntu, Apache, Wildfly, PostgreSQL) mit der vorhandenen Infrastruktur bei Netcup aussehen könnte. Ich bin dabei auf folgenden Artikel gestoßen: https://www.zivtech.com/blog/s…nd-pacemaker-ubuntu-lucid
    Meine Frage dazu: Habe ich es richtig verstanden, dass ich für dieses Setup einfach nur 2 Root-Server haben muss, Heartbeat und Pacemaker installiere (und das Setup dementsprechend einrichte), und eine Netcup-Failover-IP beantrage, die dann vermutlich beide Server kennt und im Ausfall des einen automatisch auf den anderen zeigt und dieser für diesen Zeitraum der Hauptserver wird? Falls es wirklich so einfach ist, habe ich es richtig verstanden, dass ich mich darauf verlassen kann, dass die Daten durch pacemaker und heartbeat wieder synchron sind, sobald der nicht erreichbare Server wieder erreichbar wird?

    Danke erstmal. Das mit dem Replication Manager klingt ja schon recht brauchbar.
    Das heißt, wenn ich es richtig verstanden habe, habe ich 2 Server mit den gleichen Setups und je einer DB, und wenn der eine Down ist, greift erstens das netcup-Failover, und dadurch, dass der Replication Manager läuft, sind die Daten ebenso verfügbar. Vermutlich ist es auch kein Problem, in späterer Folge weitere Nodes hinzuzufügen.
    Eines würde mich dabei noch interessieren: Muss das initiale Setup mindestens aus 2 Nodes bestehen, oder kann das komplette Replication-Konzept problemlos nachinstalliert werden für den Fall, dass ich mal mit einem Single-Server-Setup starte?

    Hallo,

    ich benötige folgendes Server-Setup und möchte, bevor es ernst wird, auf den Erfahrungsschatz der Community zurückgreifen, da ich denke, dass ich wohl nicht der erste bin mit dieser Anforderung.
    Grundsätzlich sähe das Setup für eine Instanz so aus:
    Apache -> Unterschiedliche Wildfly-Instanzen -> PostgreSQL-DB


    Dieses Setup soll ausfallsicher sein. Am liebsten wäre mir folgende Lösung (mit 2 Root-Servern): Das o.g. Setup wird in Echtzeit auf einen anderen Root-Server gespiegelt. Wenn ein Server heruntergefahren wird, soll automatisch der andere Server übernehmen. Das Problem ist wohl die Datenbank. Ich bräuchte wohl so etwas wie Golden Gate bei Oracle.


    Hat jemand Erfahrung mit einem derartigen Setup, bzw. gibt es bessere Lösungen im Zusammenspiel mit den Möglichkeiten, die mir Netcup bietet (wie zB Failover-IP)?

    Am Interessantesten ist für mich, wie ich das Problem mit der Datenbank lösen könnte, sodass diese immer lesend und schreibend verfügbar ist. Irgendwelche Vorschläge?





    In dem E-Mail heißt es unter anderem:


    Zitat

    Obwohl die meisten Aufträge ohne Änderung Ihrer Einwilligungs-Einstellungen abgeschlossen werden können, können einige Aufträge nur dann durchgeführt werden, wenn Sie zustimmen, dass einige Ihrer persönlichen Daten verarbeitet werden.


    Ich frage mich, welche Aufträge das denn sein sollen. Denn die Verarbeitung von Daten gilt als rechtmäßig, wenn sie für die Erfüllung oder den geplanten Abschluss eines Vertrags erforderlich ist. Mit anderen Worten: Keine Einwilligung erforderlich, wobei EPAG meiner Meinung nach maximal der Auftragsverarbeiter ist (und Netcup der Datenverantwortliche. Ich bekomme schließlich meine Rechnungen nur von Netcup).

    Selbst bei Domains, bei denen die Daten "Requested by contract" sind, benötigt man keine Einwilligung von uns, da die Daten (aus welchem Grund auch immer) für den Vertragsabschluss benötigt werden (zB NIC AT)

    In allen Fällen ist die Verarbeitung der Daten gerechtfertigt, ohne Einwilligung. Welche "Aufträge" sollen das also sein, bei denen man explizit eine Einwilligung benötigen sollte?